I showed the simple manual way to inject this.
var controller = new SurveyResultsController(this);
this.DataContext = new SurveyResultsViewModel(controller);
This I think is the best way to illustrate the concepts, but it's not how you'd do things normally. Normally you'd rely on an IoC (Inversion of Control) Container (such as Autofac/Unity/StructureMap/etc.) or similar mechanism (such as MEF). Entire MVVM frameworks
are built around these concepts (Onyx, Caliburn, and MVVM Light to name just a few) which you could look at for much more complete implementations of the concept, but really, the above is enough to give you insight into how the pattern(s) work.
To answer some specific questions:
Is this interface declared in the project containing the Views or the project containing the ViewModels? This is not really a meaningful question, as patterns don't care about details like this. All of the code can be in a single project (assembly)
and you'll be following the pattern correctly, for instance. If you're going to decide to seperate the Views and ViewModels into different assemblies (I'm not sure that I would, BTW), then the fact that the Views project is going to reference the ViewModels
project and not the other way around means that this interface would have to go in the ViewModels project, or in a third project.
Where is this interface implemented? This is sort of like the last question, and not really a meaningful question. It doesn't really matter where you implement it. However, since the implementation is going to have to have a hard dependency on the
View that will determine where it can and cannot go, just like in the last question.
Are we trying to get to the point where we are sending from the View project to the ViewModel "call me when you want to create this view"? Sort of, yes. I say sort of because in the more generalised implementation the ViewController will
usually be decoupled from the concrete Views as well by having the controller pick a View based on either configuration or convention. So the real point is that we're getting to the point where the ViewModel doesn't interact with the View, but rather interacts
with an intermediary (a "service") that is passed (injected) into the ViewModel. By doing so the ViewModel is no longer coupled to any specific View. This allows it to be reused with multiple Views, and also allows it to be unit tested without any
need to do UI automation, which is a brittle and difficult way to do automated testing.