I think it's important to remember that the Controller/Presenter is where the action really takes place. Coupling in the Controller is inevitable because of necessity.
The core point of the Controller is so that if you make a change to the View, then Model doesn't have to change and vice versa (if the Model changes the View doesn't have to either) because the Controller is what translates the Model into the View and back again. But the Controller will change when either Model or the View changes do because you effectively have to translate within the Controller how the Model is to Viewed how to get changes made in the View back into the Mode.
The best example I can give is that when I write an MVC app, I am able to not only have data in the GUI view, but I can also write a routine that pushes data pulled from the Model into a string to be shown in the debugger (and by extension into a plain text file). If I can take Model data and translate it freely into text without changing the View or the Model and only the Controller, then I am on the right path.
That being said, you will have to have references between the different components to make it all work. The Controller needs to know about the View to push data, the View needs to know about the Controller to tell it when a change has been made (like when the User clicks "Save" or "New..."). The Controller needs to know about the Model to pull the data, but I would argue that the Model shouldn't know about anything else.
Caveat: I come from a totally Mac, Objective-C, Cocoa background which really pushes you into the MVC paradigm whether you want to or not.