Great post! We've been through a similar migration process and reading this has been reassuring that we probably did the right thing!
But let's say someone did need to publish a change to DB2 and so you created the DB2 solution with stubs for referenced objects on DB1 -> DB12.
Then, say, DB2 did need to change the type of a column, or the name of a column, or drop a column that is still referenced in lots of stored procedures, but its value has become meaningless over time (e.g. IsActive = 1 but inactive rows are now archived, so the whole table has a value of 1 here).
Do you have a process of keeping the stubs in sync with the real DB projects? Or of publishing this change across both DBs?
Second question: Is your DB6 (say) stub for the DB2 solution the same as the DB6 stub for the DB1 solution? As more and more databases are put into full projects, do you find you'll end up with pretty much a "full" stub project of table definitions and empty procedures?