Here is a question:
1) How can I maximize what I'm learning so that I recognize design patterns when i see them and remember how to use them?
A. Read good code. Find an open source code project that you use often (so that you're familiar with it already), then dive into the source code and see how they did it...try to figure out why they did it.
2) How much should I memorize?
A. Nothing. Patterns are about making code SOLID, cleaning it up, making it extendable, making it better. Knowing the name and the problem it solves is a great way to communicate to other developers what you're talking about, but nobody is going to fault you for looking up the decorator pattern if you decide to use it. Patterns are tools, I don't know every size box wrench in my toolbox, but I know what it does and I know how it's different than a crescent wrench.
3) Or is it enough to just know the basic principles and be vaguely familiar with the pattern until I need to use it?
4) Are there any websites with exercises? Or books with good exercises so that I can practice a few of these?
A. Google 'Code Kata'; practice solving problems and determine how or if a pattern is needed.
Refactoring your old code is another good way to learn and make your old code better. Look for lengthy methods, confusing logic, long switch or if then statements...what are commonly called 'code smells'
5) How many of these patterns should I strive to learn? Is it too much to read the whole book and try to learn them all? Or again should I just try to get familiar for now?
A. There are a handful such as Unit of Work and Factory, repository, singleton that you might be using every day an not even realize it. Remember the scenario in the book and understand how to correlate it with your work.
What are your suggestions?
Read good code, find and open source project that you love and dive deep into the code.
Refactor ALL your old code, look for ways to make it cleaner, extensible, maintainable, this will expose weaknesses in your 'normal' coding.
Work to understand the purpose of the pattern, not how to implement it. One of the biggest gains of understanding design patterns is being able to communicate larger ideas with other developers.
Analogy: If your wife says she's going to pick you up some plaid shorts...plaid is the pattern...she's communicated a lot simply by saying 'plaid', how the plaid pattern is implemented (colors, side of stripes, size of squares) is second to knowing the pattern.
Just my thoughts