Yeah, it's irritating, but should not be an insurmountable obstacle for migrating schema+data. I have done this thrice for a database consisting of 40 tables and about 2.7 million rows total (DB2 -> PostgreSQL 7.something, DB2 -> SQL Server 2005, and SQL-Server -> PostgreSQL 9.1). Yes, I know that those numbers are small-ish, but the data contained a lot of user input and included every quirk and special character under the sun :)
This database was storage for a Java application using Hibernate, which likely evaded some obstacles (see below). The procedure took a couple of days in each case: export schema, change a few data types in the schema (bool/int, date/datetime and so on), after which the inserts work if you pay attention to string escapes, encoding, and so on. I scripted the conversion in each case, so that every test iteration started from a fresh dump. I tested it by exporting all data from both DBs to native language data types and diffing the results.
Of course you can get in a lot of trouble if your client software is not using abstraction for db access, I suppose that some software contains quite a lot of literal SQL in the source, and SQL syntax differs in amusing ways. In some causes I can see no other reason for it than "because fuck you, that's why". Also, if your client software relies on non-standard features of a specific RDBMS you might have to rewrite to account for that.
So yes, I would very much like for all vendors to have a standard-compliant default mode, from which exported data would seamlessly import into other RDBMS's (re. sig, how do you write that correctly?). Sadly, most vendors (apart from OSS alternatives like PostgreSQL which should bend over backwards to make migration easier) have no interest in making it easier to switch to another RDBMS, so this will never happen.
Granted, I was part of the team developing said application, and DB portability was something of a pet peeve of mine, for which I was very thankful during the migrations. Due to that we had few DB-related issues during those migrations. I'm not even a DB-admin by trade, so most real DB-admins should have no problems doing what I did.