Can't talk for the other NoSQL players, but for Redis this is more or less impossible since the key-value business is something like 10% of the current API. How to cover the other 90%?
Maybe in the future Redis may be able to listen in another port to talk the memcached protocol, but this is not an high priority feature for now.
What I think people should do is to abstract the interaction with the DB in their code. So that it's just a matter of writing adapters to support new KV stores, and this adapters can take advantage of peculiarities in specific stores.
For instance if using Redis one can use Redis Sets to take the list of friends. When using something different will serialize data as JSON, and so forth.
Since a lot of these different data stores have fairly different semantics, I'm not sure how much value there is in trying to create a common set of abstractions in your code.
And so forth. You can switch from SQL to a NOSQL solution and so forth without to touch the app but just a single file with all the DB API.
If it's at very low level like Db.get(), DB.set(), ... is still useful if the application just using a strict common subset of features (get/set/exists/expire/incr).
Maybe in the future Redis may be able to listen in another port to talk the memcached protocol, but this is not an high priority feature for now.
What I think people should do is to abstract the interaction with the DB in their code. So that it's just a matter of writing adapters to support new KV stores, and this adapters can take advantage of peculiarities in specific stores.
For instance if using Redis one can use Redis Sets to take the list of friends. When using something different will serialize data as JSON, and so forth.