The GoF patterns can be applied to any system design, If you are looking for concrete examples, then you are thinking about them completely wrong(no offense intended at all). It is common at first to think that way.
I could say for example, starting with what is arguably the simplest and most common, a Poker Game that only ever has one deck might be a candidate for the Singleton Pattern. The Singleton ensures that there is only ever one instantiation of a class. There are a thousand different scenarios where this may be the case.
The same Poker Game might likely use the Visitor Pattern to evaluate each hand at the table. The Visitor is used to Iterate over collections of objects and perform just about any kind of operation on an individual object or composite.
At the same time you might say that a Hand is a Composite made up of individual cards which by themselves could be considered a leaf object of that Composite type Hand; in which case the Composite Pattern in conjunction with the Visitor would be used (they often are used together) with the Iterator Pattern.
The Observer Pattern may be working at the same time, as each player would be registered with the dealer who is essentially driving the game. If the game has AI players, the Strategy Pattern could be used to swap out algorithms used to drive the AI players decisions based on the ever changing dynamics of the game. Actually, as I re-read that, I should have mentioned the State Pattern here as well, State Machines are typically used for AI systems.
The Decorator Pattern could be used to add unique behaviors to the individual AI players, or to change the way the graphics are drawn, or diversity of background noises or both and more, at run-time. I probably shouldn't forget to mention FlyWeight in that context as well. FlyWeight Decorators are really cool.
Patterns, not just GoF, are a philosophy of design, with the intent to solve Anti-Patterns that are typical pitfalls of any design process. You can be creative with them to the limit of your imagination.
Patterns are just the opposite of concrete, in that they promote the cardinal principles of OOD, like programming to Interfaces rather than implementation, or promoting lower level dependencies to the control of higher level abstractions, or the Open Closed Principle (Open for Extension; Closed for Modification) like the Pandora's box analogy.
While it is best, in my opinion, to leave Pattern implementation as loosely coupled as the code it helps us write, there is solid convention to be considered with their use. Each Pattern was developed with a typical motivation and intent. They are also conveniently categorized to reflect this, as there was an original Anti-Pattern(and still is) that motivated the design of each one, as well as typical combinations of certain patterns that work quite naturally together.
The way in which one approaches the concept, or better, the philosophy of OOD, will have a direct influence on that individuals ability to implement Patterns effectively. Incidentally, it does have a requisite AHH HAA! moment, which is the only real contingency tied to their effective, and creative use.
