You have four options.
ONE The first is a service, just like @Ask-too-much explains. In fact, this is a beautiful solution if you like it.
The benefits of the first solution are that it is reusable. If you are not reusing this UI, a dedicated service might be overkill, to be honest.
TWO The second is a view-model event. That is to say, your Page can subscribe to your view-model's event (let's call it ShowContentDialog) and when it is raised by the view-model, your Page handle its presentation.
The benefits this approach is that, just like the first approach, you are offloading the effort to another class. In this case, you are creating what is likely a one-off solution without needing a service, a service interface, or injection of that service somehow. If you are not waiting for the result of the event, then I think this is idea for 99% of issues like yours.
THREE The third approach is to use a different control that can be bound to a property. For example, since you are already using Template 10, you can use the ModalDialog control which has an IsModal property. A property in your view-model (let's call it IsModalVisible) can be used to control the dialog without coupling to it.
The good part of this is that you get to invoke the dialog from the logic of your view-model, just like the first two approaches. But unlike the first, you do not need a service. Unlike the second, you do not need a handler. It's the most "data binding" way to do it, and likely what I would do.
FOUR The fourth way to do it is to use messaging. Messaging is the mechanism one view-model uses to communicate with another. IN this case you could use messaging from your view-model (with a message we might call ShowDialog) that is listened for, not in another view-model, but in your Page. This would work fine, too.
The down side to this is that you need a messaging solution, but you might already have that. The up-side is that the logic for handling the visual could be relocated at any time as Messaging is multicasted to anyone listening.
If I were you, I would consider number 3 first, perhaps. Without a little more understanding of your app scenario, I can't be sure. You are a developer, though. All four of those options are good. Just be sure not to be tempted into passing the UIElement into your view-model. That's needless nastiness :)
Best of luck!