I've been very interested in the progress of the entity framework. Recently, the June ctp was announced.

It boasts some new feature I had been waiting for, like the ability to detach the object from a context. This is necessary when you want to work in a disconnected manner. It would be fantastic if we would be able to retrieve a graph (spanning is now supported) and send it to a client, having the client change it and then reattach it to a new object context on the server. This would mean having to do change tracking on the client yourself, which does leave for more flexibility in your serialization format, as compared to using strange change tracking iEnumerable implementations that are out of your control.
This is the path Microsoft is taking. There is no real persistence ignorance yet, but they might be heading for a comfortable compromise.

Which brings me to nHibernate. The project I'm heading is a pretty big client-server application, which we are migrating to-wards a more flexible n-tier. We are rebuilding the client-side with WPF (for other reasons) and are implementing WF in the back-end to manage our processes. We have build our own naive OR-mapping layer on top of the datasets that were already in place. This has allowed me to delay having to make a choice for a real OR-mapper.
I have had some great experience with nHibernate, having used it since the 0.7 beta. Lately I have not had the opportunity to use it, but it seems the 1.2 release has added some major missing pieces of functionality like SPROC support and generics. I have some time left before I will have to choose between entity framework and nHibernate but I can already see it's going to be tough:

The generated code is ugly and although they have listened to the persistence ignorance argument, it seems too little, too late. Their V1.0 implementation might be an attempt to do it correctly, but if they had just listened earlier, their approach would have been much cleaner.
nHibernate is based on a proven concept and is very clean (although the code-base wasn't clean when I stepped through it ). It has a great community uptake. It, however, still lacks good modeling tools and it only has one dedicated programmer.

In the end, if Entity Framework turns out workable, it might be the better choice. It will get a big community (although a large part of that community will consist of programmers that don't even know of the alternatives), it has a big team of smart people working on it (although they needed quite a few tries to get it right) and it will have great visual tools (love it). In the end, most importantly, when I hire new people for the project, they are more likely to know EF then nHibernate. Is that a good reason though????