Reading an interesting post from Dwhittaker, I think the problematic is broader. It appears through the question on how should I build my entity from the DAO object. To my opinion, the DAO object should be as much simple as possible…not smart at all. The best is to generate it using byte code generation for example using annotation in the real entity object for example, buit this should be addressed into another post 
If the DAO object is generated, then the entity (or value object) can be build by generic code using reflection for example. Then the “real” question raise: what about information lost during the entity creation. Let me explain with a very simple example: waht about the Id of the DAO object? It has absolutely no sense in the entity object, but is required when the application push back the entity object to the persistence layer to store changes. This topic is highlighted in this post of Ayende and expose another example: detection of changes.
The problem is about keeping track of information on an object (the entity) without exposing it. more over, this object can be moved from a process to another (or webservice). This sounds very close to the state in ASP net pages, which provide a very good answer. So, I wouold advocate to store a state in the entity object that is crypted and reused by the persistence layer.