lair

Service Broker

Пункт 0: используйте EF CodeFirst или POCO templates, тогда у вас будут «чистые классы» in the first place.
Пункт 1: все нижесказанное верно до тех пор, пока у вас контроллер работает напрямую с DAL, а не со слоем бизнес-логики или сервисов.

Есть таблица dbUsers в базе. В EF создаются классы dbUsers. Неким образом создается класс User. Слой данных работает с объектами EF а пользователю (контроллеру) отдает красивые чистые объекты класса User без лишней информации.

Это лишняя прослойка.

Есть таблица dbUsers в базе. В EF создаются классы dbUsers. Слой данных напрямую работает с этими объектам и передает их в контроллер. Т.е. контроллер работает с объектами типа dbUsers…

Это вполне нормально.

К счастью, EntityFramework в последней версии поддерживает простейшие миграции автоматически и в девелоперской копии данные не теряются, но что делать с продакшн копией в которой куча данных?

Если вы используете EF CodeFirst migrations, то вы можете сделать любой код по миграции данных.

Ведь при следующем паблишинге на сервер зальется полупустая девелоперская БД? Как настроить студию чтобы она обновляла структуру, но не трогала данные?

А что вы понимаете под «паблишингом»?