When you write a service/Web API controller method that returns IQueryable, you have made a conscious decision that your HTTP resource is a collection. The collection may be empty ... but an empty collection is as valid a resource as a full collection. The collection was found and the correct response is 200, not 404.
If you're HTTP request was for a specific item (eg.., you had an endpoint designed to return a single object whose route was something like ~/customers/:id), then returning an HTTP response with status 404 makes sense. You can have both kinds of endpoints if you wish. Breeze doesn't force you into IQueryable. That is just an option. You can have a mix of both kinds of endpoints.
For me, the larger concern is a possible confusion between data (the customer(s)) and UI (the page). The Web API isn't returning a page; it's returning data.
I'm assuming you're building a "Single Page Application" which has a detail screen. You do indeed have to decide what should happen if you navigates to a detail screen, try to fetch the entity for that screen by Id, and discover that such an entity does not exist. Now you have to decide where to go.
That decision is independent of the HTTP status code. You can re-direct your client-side screen to a safe location (e.g., the list of Customers) without worrying about HTTP status codes. HTTP status codes are part of the HTTP protocol for communication over the web. Your application's own client-side screen navigation isn't crossing the web and there is no need (and no point) to adopting that protocol.
You should be just fine detecting that the Web API returned an empty collection. There is no embarrassment. The HTTP police will not arrest you. Just re-direct as appropriate.