Нет, не предусматривается. 100% есть такие тулзы, но я не интересовался. Насколько я понимаю, это нужно на начальных этапах когда мы пишем приложение читающее из уже существующей базы. Миграции здесь не нужны.

Да, такие инструменты есть. Но проблемы те же: автогенерация модели классов с нуля, недостаток выразительности и "оторванность" от синхронизации в другом направлении (от классов к схеме), что заставляет использовать два разных инструмента на разных стадиях разработки. Однако перенос изменений из базы в структуру классов необходим не только на начальных этапах. Допустим, может возникнуть ситуация, когда нужно объединить базы двух разных приложений, а использовать структуру классов со стороны Вы по каким-то соображениям не хотите.

Show me the code. Пока это выглядит как "бла-бла-бла мы новый мир построим". Дьявол в деталях.

Здесь не могу не согласиться с тем, что нужен рабочий демонстрационный пример. Но, к сожалению, пока что это только идея. Собственно, цель топика — понять, как к ней отнесутся и узнать, не изобретаю ли я велосипед.

Стоп, вот у нас есть 2 сущности: модель в коде и схема данных в БД. Чтобы их синхронизировать вы предлагаете добавить третью (данные для визуального редактора)?

Модель классов может быть не только в коде. Строго говоря, модель — это не обязательно сам код. Допустим, если Вы обратите внимание на такие инструменты, как EMF, например, то обнаружите, что модель представлена в виде диаграммы классов в визуальном редакторе и уже по этой модели генерируется готовый код. Не вижу в таком подходе ничего предосудительного.