This is a really great idea and something that should be a big usability win as more and more people use yt with particle datasets. I have several comments, questions, and suggestions but overall an emphatic +1 on this eventually making its way into yt.
Is ParticlePlot a subclass of PlotContainer? Does it make sense to do that? For all the other plotting classes there is a sense of a list of fields to loop over and store plots for per-object. Your plotting class could accept a list of x and y fields (does it?) so I guess you could store all permutations of x and y field combinations and make a plot for each one, although I'm not sure if that makes sense.
Should we perhaps instead have a class that splats particle positions onto spatial axes and another that does the same for arbitrary combinations of fields like ProfilePlot and PhasePlot? One issue with your second example is that the aspect ratio isn't equal for both axes, which is presumably why your spherical distribution of particles appears a bit squashed. It would be straightforward to handle this if we know the x and y axes are spatial, less so if the plotting class has to handle axes with generic dimensions.
I'd prefer it if we could keep the plotting code as unified as possible. Optimally, this means that individual plots should subclass PlotMPL and ParticlePlot would subclass PlotContainer. Doing so should reduce code duplication and also ease maintainability going forward. That said, I totally understand that you have the code written already and don't want to force you to rewrite a bunch of stuff you've alrady written. One bonus of using the plotting infrastructure that's in yt right now is that you should be able to wire up the PlotWindow plot callbacks, at least for plots that have spatial fields along both axes.
It might be useful to hash this out in a YTEP.
Hope that's not too much feedback - if you can't tell i'm excited about this!