First, did you take a look at my systemd services for x11vnc and mediacenter? Of note, several of the settings for the x11vnc are different, including some important ones (like setting the display and picking graphical target rather than multi-user.target). With autologin configured, my two services both automatically start x11vnc and jriver on boot and restart them if they fail, so that's a solved problem. These won't solve underlying x issues if that's at play.
https://yabb.jriver.com/interact/index.php/topic,108981.0.htmlDepending on how much you've done, you might want to take a step back and start fresh. Depending on your virtualization setup, you may not actually need an xorg.conf or the dummy xserver, as most virtual environments can expose virtual "real" displays for the guest OS to use/connect to (i.e. the guest VM thinks it has a monitor attached and behaves accordingly), and you'll be better off using the VM's virtual display rather than the dummy xserver as the VM displays are less quirky and have advantages (like hardware acceleration). That may not be an option in your virtualization environment, but I mention it because it may save you labor and frustration.
I'll talk through some of the problems and then offer some advice:
1) The reason MC fails when you start it from the command line is that the DISPLAY environment variable is not typically set in an ssh session. You can solve this by issuing the "export DISPLAY=:0" command before trying to start MC, or adding it as an environment line to your systemd startup service (see my example above). This assumes you're using the actual display (typically ":0") and not a virtual one (":1" or higher). Other environment variables can be important too (user for example).
2) Your service targets the multi-user.target; this will not work correctly in all cases as multi-user.target does not guarantee an xserver is running. If you start the VNC server before the xserver it can fail or make a virtual display (which no longer works correctly with MC in all cases). So you want to shoot for graphical.target which is the target that ensures a running xserver. In fact if your default.target is set to multi-user, systemd won't even try to start the xserver.
3) Your inclusion of "After=display.manager" mitigates 2) iff you have a display manager installed and configured. You don't mention how you configured things at install time, but it's not clear that you have a display manager installed (you don't mention installing one). Obviously setting services to start after the display manager will have problems if there is no display manager installed.
Now my advice:
Two choices:
1) Start fresh and ensure that you choose xfce4 as your desktop environment in the task selector during install. This will ensure that X is correctly configured with a display.manager to start on boot. If you install it after the fact there is no guarantee that the automagic will happen. If you do this, you'll need to modify /etc/lightdm/lightdm.conf to enable auto-login.
2) Fix your existing install by making sure you have a display manager installed and that X is starting correctly on boot and logging in. Try the modified systemd services I linked above and see if they work. If you do have lightdm installed configure it to autologin to allow everything to start smoothly at boot.
Those two services and the lightdm tweaks are really all you need if you used the debian installer to install xfce4 and display manager. If you didn't install a desktop environment on boot, or installed Gnome, you have some backtracking to do. Make sure to install and set lightdm as your display manager, and make sure the default.target is set to graphical. Gnome's display manager (GDM) requires more configuration to enable auto-login and the steps change frequently between versions (and it won't always run right over VNC anyway), so lightdm is a better choice here.
I was just spinning up a JRiver debian VM (testing my technique and scripts for the stretch upgrade) so I'm fairly confident this all works pretty well.