Steve, while this is all possible - and in fact exists - I have a couple of concerns about how the issue is framed.
You speak about "not knowing which SQL Server you are connecting to". The problem is it still assumes MS SQL Servers. The real issue we face today was well framed by Fabian Pascal in 1992 (don't start booing...for one thing, the book I am referencing is one in which he vigorously defended SQL as a language).
The relational model freed the developer from the navigation details of "the database". What has happened since is that "the database" has become "the databases"; multiple databases on the same or different servers, which may be running SQL Server, Oracle, DB2, or simply be some kind of tabular file.
In other words, "the database" grew so it was larger than the server, even though it is represented as if it were multiple databases. In his chapter on Distributed Databases, 17 years ago, showed the need for DDBMS - distributed database management systems - that would free the developer from the navigational details of 'which database on which server'. (Fabian Pascal, Understanding Relational Databases with Examples in SQL-92, 1993. It's available for about $2 used, it's perhaps the best intro to RDB out there aside from the Manga book).
Interoperability wasn't in any vendors short term interest, so the DBMS vendors never got into it. Meantime, ODBC came about, the concept of web services (which is a fine layer to separate on) came in, and products like Attunity came about. Attunity doesn't seem to have gotten substancial market traction, unfortunately, but the concept they followed clearly works, as every time someone came up with a new way to represent tabular date (eg XML), they just wrote the one module needed.
Developers shouldn't know from clouds or vendors or servers. They should know how to get data by stating "what", without any "where" or "how". We had that early on with DBMSs, but we've now lost it. Just putting it on a cloud isn't going to solve that, we need to be able to apply relational operators between servers without realizing we are doing so.
Debating the cloud won't get us there. The whole point of database theory is that We Don't Care About Implementation. And if you are adding complexity for DBAs, it won't be more work for DBA's - no one wants to spend money on that - it is just more frustration and burn out for DBAs.
Of course, I could be wrong.