I don't think building the interaction modes as different "controllers" will serve you well. What is your logic for this? A controller is to tie display and your user input to your model, but im imagining that this is only one canvas and one mouse pointer, so why multi controllers?
You could have the switching logic that changes between interaction modes in a model class. You probably shouldn't need to use it in more than one controller unless you're giving your user drastically different "canvas" type elements and layouts to draw on also. Either way, I think some good choices of Design Pattern would be a factory and/or a decorator or something similar.
Collect the event from the button click on the palette of interaction modes (you mean this to be a sort of Photoshop/MS Paint kind of toolbar on the side, right?). Use that event as the input to a factory. This factory will generate an instance of something adhering to the "Tool" interface (or whatever you want to call it). The newly generated Tool instance is stored in the controller somewhere to be ready to receive mouse input as the user draws, for example.
If you want to get complex - like what if some tools can be simultaneously chosen, like both a "magnetic lock" and a "draw" - your controller's reference to an instance implementing a Tool interface would need to be extended at runtime somehow, like w/ a Chain Of Responsibility pattern (or a decorator as previously mentioned). Now the factory mentioned before will make more than one Tool. The controller will "line these up" in the case of the Chain of Command before passing the user's mouse input. For example, the magnetic lock "Tool" implementation may change the users input slightly to exist on a guideline before passing it "along the chain" to the drawing tool.
