Memcached is an in-memory key/value store. Redis can be used that way, but is much much more.
Ways Memcached and Redis Are Similar
Both are capable of caching database results or anything else you might want to cache.
Both are capable of storing simple string values for a key. A previous answer stated memcached is more flexible, and this is completely false. Storing "whatever you want" into memcached involves taking objects and serializing/marshaling them into strings. Redis supports this equally well. Redis is generally more flexible even at storing your serialized objects as the default max value size is much bigger (1MB vs 512MB).
Both store values in-memory and are extremely fast and efficient, often bottle-necking on network bandwidth or memory I/O without heavy CPU usage. Both are highly scalable. Great tools for management and monitoring exist for both. Commercial cluster solutions exist for both. Redis Cluster is available in beta, quickly approaching being available in the default stable release. This will give Redis out-of-the-box clustering, something memcached doesn't offer.
Update 10/9/2014: Redis 3.0 (with Redis Cluster support) has exited beta and is in Release Candidate mode. Enjoy.
Virtually every use-case for memcached can be solved equally well, sometimes better, by redis. Memcached is a fantastic piece of software, but both its features and strengths have largely become a subset of Redis's.
The Redis Superset
Where they differ is in the large number of additional features redis offers, and the additional use-cases those features enable.
Redis is more than a key/value store. It is an in-memory data structure server. Keys can be assigned simple strings, like in memcached, but they can also store Hashes, Lists, Sets, or Sorted Sets. These additional data types are very efficient and optimized, with many commands to leverage them, enabling access patterns a simple key/value store doesn't offer.
Redis offers persistence, built-in and out-of-the-box. This means redis is a real database by default, and not a simple volatile cache like memcached. Your data will be there when you restart. There are lots of simple administration options you can use to tweak the persistence to best solve your use case, or turn it off if all you want is a volatile cache.
Redis offers pub/sub (Publish/Subscribe). This allows you to create channels and have one or more clients subscribe to them, allowing an efficient high-speed real-time communication mechanism. This can be a great solution for inter-process, inter-application, or inter-server communication.
Redis offers Lua scripting support. This allows you to do all sorts of new things. One important example would be executing several dependent redis commands atomically, and with a single call to redis. Lua scripting is easy to pick up and the scripts run efficiently and atomically. Lua is to redis as SQL is to traditional RDBMS (Relational Database Management Systems, ie: MySQL, PostgreSQL, etc.).
Unless your project is already using memcached or your organization has significant investments in memcached, you should not use it. Redis at least equals memcached at its own game, and enables a whole world of new ones. Even if your problem can be solved equally by both tools, go with the tool that provides more flexibility for problems you can't yet foresee: redis. You will also be choosing the tool that is more actively developed and maintained, and which is being improved more quickly. Memcached isn't going anywhere and shouldn't, but its hard to make the case for it being used in anything new unless you have significant knowledge or infrastructure investments in memcached.
If you are already using memcached, switching to redis may be a lot of work for little to no gain. Evaluate redis closely and decide for your situation whether the costs of switching outweighs the benefits. If it does, stick with memcached. It still is a great, stable, hardened piece of software.