This approach has a few problems. As with anything that's supposedly transparent, the approach trades robustness for ease-of-use, and I'm not convinced that the ease-of-use performs well enough (or at all, in some cases) to justify the additional effort.
The first is that many SQL queries are inherently non-deterministic. For example, consider the following query that selects 10 random rows from a table (and I'm aware it's not a good query for other reasons, but bear with me):
SELECT * FROM `table` ORDER BY RAND LIMIT 0,1;
This query, if cached, will return the same set of rows every time the cache is hit. In the case of a DB-agnostic transparent SQL proxy, it would have to be specifically informed that this query produces volatile results. You can either do this manually, by breaking the SQL statement's compatibility with the native RDBMS, or you can try to guess what the RDBMS is going to do with the query.
The second reason it's not really workable is that it breaks any functionality that isn't directly caused by the CREATE/UPDATE/DELETE operation. We're talking about triggers, stored procedures/user-defined functions, and other backend functionality that isn't, strictly speaking, "SQL." In some cases, like Pl/Perl or Pl/Python, this could be mitigated with custom functions that let the database server try to flush the cache. The design of it leaves a bad taste in my mouth, though.
There's stuff that occurs on the frontend that is DBMS-specific, and you might not be checking for it. For example, most of your updates in MySQL for an application that does a lot of updates might not be coming in the form of an UPDATE query, but they might be taking the form of a parameterized query where everything is streamed as data by the MySQL client libraries rather than ferried across as SQL statements. Is this the kind of backend engineering anybody actually wants to do?
The third reason is that lots of queries return a lot more data than you probably need to cache. The DBMS has a query cache and a buffer pool already, which is pretty good at doing exactly the type of caching you describe. The reason that memcached is useful is because developers have more control in caching the data that's important, rather than just throwing everything at the cache that comes out of the database. Adding another layer of cache with the exact same contents as the DB's cache and an additional layer of indirection and another point of latency won't speed things along any.