Don't look for trendiness
Any standard programming solution to a certain problem can be considered a design pattern, it doesn't matter how popular they are, or if other programmers use them or not.
You might already be using a design pattern that hasn't been invented/specified yet.
Don't try using them, try thinking in their terms
The problem with design patterns is that sometimes programmers want to fit their problems into them when it is the other way around.
Remember design patterns' design convention have a typical problem to solve, you can even combine design patterns to tackle other bigger problems. This is kind of typical in Service-Oriented Architectures, just see some of the SOA patterns there are.
Look for them in the wild
There are plenty of open source projects where you will find applied design patterns. One example that comes to mind is Joomla: you will find singletons, observers. GUI libraries will have the decorator pattern, command pattern implemented, and maybe even flyweight.
There are other patterns such as data patterns, for example the Doctrine Project alone has used, the active record pattern (1.x), entity manager pattern(2.x), unit of work, repository, query object, metadata mapping, data mapping, and other more general ones like the strategy pattern, and decorator pattern.
There are just so many interesting solutions to choose. See Martin Fowler's Patterns of Enterprise Architecture, there are also data model patterns.
Just learn them for when the time comes
Learn them, know them, obsess over them and when the time comes you'll know how to solve programming problem x, you will be a better programmer already by that time.
Become an architect
I'd say that being able to think in pattern terms to solve problems, effectively turns you into a software architect. Even if you don't want to be a software architect per se, your solutions will have more technical quality, be cleaner and better scalability —in terms of design— by default.