Design patterns covers a broad area. I'm going to assume that your students are beginners, more or less.
Elementary Patterns
A few people have developed some interesting elementary patterns for things as simple as loops and selection: http://www.cs.uni.edu/~wallingf/patterns/elementary/
These patterns help students program at the lowest level and, after introducing the patterns you can easily come up with small exercises that see whether the students actually use the patterns to guide their programming. Any exercise that requires a sequential if structure can have the students factor out the structure as a method and apply the "Return, Not Else" pattern, for example. There are many possibilities.
Organizational Patterns
In addition to coding patterns, organizational patterns can be used to both teach beginners good skills that will serve them well in the classroom and later in employment. For example, you can consider Extreme Programming (XP) or Scrum to be defined by simple pattern languages in which the practices are the individual patterns. Some of those practices may not be appropriate for beginners, but others are just good practice. For example, Pair Programming and Test First Development work well together and help students solve their programming problems. An in-class exercise in which you let students practice just those two skills under your guidance is, in my experience, very valuable. I've also presented larger projects to students as a deck of "stories", the Product Backlog that gives beginners an overall decomposition into the parts of the solution they need to build. Often this is better than a narrative explanation of the problem when the still have no design skills.
Classic Patterns.
Many of the classic patterns are amenable for use in the beginner's curriculum. They will likely do these things anyway, but by formalizing the discussion of them introduces them to the value of patterns. For example Iterators are now ubiquitous in many languages. If you are doing GUI programming then the Observer Pattern is now standard. At a slightly higher level Model-View-Controller (MVC) can be discussed. This gives you a good way to discuss separation of concerns in programming. You can also organize your course so that you make it clear that, say, at the beginning the students build a Model without concern about how it is manipulated. It has a public interface of a few methods only. Then, once you have a model you can talk about the possibilities of (perhaps multiple) views and the associated controllers. But this is an organizational issue about the course. If they have to just build everything, they might wind up with a "Big Ball of Mud" (a pattern in fact, but not a good one).
Once the students are familiar with the idea of patterns you can introduce them to more complex ones with many parts. I find the Strategy and Null Object patterns to be useful in teaching polymorphism. With these patterns you can modify the behavior of an object dynamically, which leads you to program by composition (an object has interesting parts), rather than by inheritance. For example a situation in which an object must perform in one way the first time it is sent a message, but otherwise thereafter can use strategies, formalizing the behaviors, without using ad-hoc if-statements.
I realize I haven't given you many "exercises" here. My suggestion is that you can adapt many/most of the ones you are already familiar with to the use of patterns.
Pedagogical Patterns
You can also formalize your teaching methodology using patterns, so that your student interactions are guided by well-tested methods (patterns) that can make you a better teacher and make it obvious to you (and maybe to your students) why you do the things you do in the course.
