Here is an interesting discussion about this topic. Apperantly you will not be able to just take any object and persist it using the Entity Framework. You need to either inherit from a base class, or (in the future) implement a set of interfaces. I can't figure out what the reason for that is. It is not as if supporting POCO persistance ignorance is hard or complicate the framework (at least not compare to the issues of the persistance and querying themselves).
One of the goals for NHibernate is that you should be able to develop your application where only the controller has a reference to NHibernate, nothing else. This is quite important in a number of scenarios. From wanting to keep the model pure from persistance concerns (and be able to change ORM providers) to needing to do the more complex stuff with greater flexiblity.
One case that I had realy great success at was generating mapping at runtime for a set of objects that were returned from a web service. The way it worked was that I got the WSDL, generated the code, generated mapping, and started persisting, all at runtime. I had a naming convention that made sure that I would be able to query everything properly, and it made everything so much simpler to work with.
As an aside, I am looking for the documentation for the Entity Framework, preferably some overview + architecture. Any good sources (I know about the Linq examples for Entity Framework)?