I think to do what you want, you would have to implement the OData REST protocol yourself on the client side, for instance using Atom XML or JSON (both supported).
But if your are open to it, I would suggest you consider using basic WCF Data Contracts and Service contracts and define your own perfect service interface between tiers instead of coupling it too closely to your data model. Microsoft makes it easy to expose your Entity model to other tiers for rapid development, but this can have some serious downsides. For instance, changing your Entity model can cause undesirable upward changes through the other tiers. My team started out that way and quickly ran into issues, so in the end we elected to spend more time on defining the exact contracts between tiers, modeling our business objects and then implementing the DB persistence in what ever way we wanted. For instance, we moved away from the Entity Framework, and switched to Dapper.NET without having to change other clients of the service.
Even with WCF Data Contracts, you may still end up generating client side contracts when you create service references to your service. But you can avoid that by sharing your Data Contract DLL so the client and server have exactly the same class and no duplication. I would only recommend that if your projects are all under the same SDLC.
One of the tradeoffs you will have to decide on is a choice between maintaining translations of data objects across tiers for flexibility, or coupling all of your tiers tightly on the same exact model using less code.
