One thing to consider is that L2S "does it for you" by creating the objects in an extremely large DBML file. You can work with your objects by creating partial classes, but if you decide to try to make any changes to the dbml files you are screwed because L2S will either overwrite your changes when it regenerates itself or you will have to implement any changes manually going forward.
So you are kind of stuck because its a terrible idea to change the DBML, but because of that there are limits to what you can do in terms of naming properties of your objects. A classic example is in the case of using enums that get stored as ints in your database. Lets say you have UserType as a enum in your app, in your user table you would probably just store that as an int column named UserType. Thats great except when you create your DBML file you get UserType mapped as an int column... but if you really want the property UserType to return a UserType enum you are forced to either hack the DBML... or change your naming conventions in your database to match your ORM tool... neither of which are good options.
Whereas nHibernate is just an XML based mapping between YOUR objects and YOUR database which gives you significantly more flexibility in terms of how you want to set things up.
another thing to look at is the many-to-many relationships and the table-per-subclass/ table-per-class mappings that are referenced here:
http://nhforge.org/doc/nh/en/index.html
I don't believe that L2S can handle table-per-subclass relationships.
Hope this helps,
-Max