ALEXBORБудем думать насколько она реально реализуема с нашими ресурсами...
Мне кажется, тут вопрос не столько в ресурсах, сколько в проекте. Трудоемкость реализации такого движка достаточно четко определена, прибыльность определяется размером проекта (и соответственно трудоемкостью кодирования для каждого случая отдельно), итого получается "точка окупаемости", которую проект либо достигнет, либо нет.

Разумеется, движок также не обязательно писать "сразу и в полном объеме", есть простор для поиска оптимума. Мне кажется важным то соображение, что если вы ориентируетесь на "настоящий результат", то заложившись сейчас "только на Hibernate" или нечто подобное, вы можете сами себе подрезать крылья.

Возможно, я бы сделал так. Набросал бы основу прослойки (это быстро), не писал бы генерацию кода, написал бы только поддержку задания кода для каждой конкретной БД. Ну а потом начал бы потихоньку, сообразуясь с потребностями, наращивать метавозможности. Таким образом был бы достигнут компромисс между "не писать большого движка сейчас" и "не придется переписывать уже готовый код в будущем".

ALEXBORЯ о ресурсах говорил в плане того, что если у нас есть возможность использовать разработчиков одной и той же функциональности под каждую СУБД, то и прослойка никакая не нужна. В любом случае за универсализм придется заплатить лишним промежуточным слоем... ИМХО
Хм. У меня такое ощущение, что я чего-то не понял, а в процитированном содержатся противоречивые утверждения.

Промежуточный слой нужен для того, чтобы "все прочие модули" думали в терминах бизнес-логики, а не СУБД. Лишний ли он.... не берусь утверждать, что именно так, это полезно в любом случае, ну а при прицеле на несколько СУБД просто необходимо.

Ну а насчет "той же функциональности под каждую СУБД" - минус этого в том, что это дорого и хлопотно. Поэтому в идеале так следует писать только ключевые фрагменты, в которых иначе крайне пострадает производительность. Как я написал, можно рассмотреть вариант постепенного перехода, благо прослойка скроет все эти детали и позволит прозрачно переходить от кучи частных реализаций к обобщениям.