I just thought that I would chime in. For me, the main reason to use WCF is to create secure, distributable applications where numerous clients can access a secure service host. By far, the biggest challenge is the "disconnect" that takes place.
For example, if a client opens a screen to edit a User, under-the-hood, a request must be sent to a service, the service must fetch a list of users, send the list back and the client must display the list. Then the client selects a user to edit - again - a request to get all the appropriate details must be sent, the sevice must query the database, populate the dat in an object, send the object back to the client, the client then displays details of the user.
Here is the issue: there will be implementations on a proxy (client side) object that are for use with a UI, client-side validation, etc. The service does not need many of the client-side featurs, but does need features related to security, server-side validation, persistence, etc. In other words, using one big obect to accomadate both the service-side and the client-side doesn;t make sense becuase it makes the object too large and ineffiecient for transfer. Further, it can expose security features to a client if the same object(s) are used for both client and service side. Thus, from my experience, it makes sense to have both a client version of objects and a service version of objects. I declare common interfaces when building the objects and have massively customized the ES templates.
For me, the proxy needs UI features like INotifyPropertyChanged, not the service. The service needs to create objects with the security permissions of a user so that business logic, queries, and responses are based on security context.
I have wanted to share, but my templates are so highly customized that it really would not be easy at all. I am looking for ward to the "layered" model - I hope that is progressing well.
In general, I have the "Generated" objects normally created by ES output into a service-side library - these objects are customized but are somewhat close to the ES defaults. The major differences are copy constructors and methods and the implementation/declaration of an auto-geberated interface with each object. My client-side objects are created in a different assembly and have virtually nothing in common with the original ES defaults. Every object has an interface comprised of the public properties auto-declared. This way my business logic interacts with interfaces and I can pass in a proxy(client-side) object or a service-side object.The interfaces themselves are auto-genrated and stored in the client-side assembly. It also allows for copy constructors to be auto-created. If a client sends a proxy to the service, the service "news up" a service-side object with the appropriate security context based on the user, and the proxy object. This way I don't "have" to requery or refetch the object. I should note that I do reload objects when changes are requested to be persisted so that the service can verify that properties that are not saved outside the security context of the user - they are always are left properly intact. For example, some users may not be allowed to back-date a document. If they somehow manipulate the client application, or a design error occurs, or via any means and they manage to backdate the object and request it be saved, the service will check the persisted date and the date sent by fetchting a fresh copy, if the date is invalid, the transaction is rejected, and a security protocol for violation of policy is triggered.
My description is very trimmed down, but I am trying to say that the layered approach - again - assuming it is working out in development for 2008, would be absolutely AWESOME!
At that point, I believe I could share features. I am excited - even drooling - waiting for the update. Until then, my templates are nowhere near your templates (my dog is better than your dog ) - he he 
Trevor