I strongly suspect that you will never see systemd working on the Windows NT kernel. Getting systemd to work doesn't just involve supporting the Linux kernel system calls, but also involves getting what those system calls do to work as well. It's all very well supporting open(2), but if one cannot open (say) /proc/self/mountinfo or all of the stuff under /sys or many other things (some listed at http://0pointer.de/blog/projects/the-biggest-myths.html), then systemd might load but it won't run and work.
The same goes for upstart. For example: upstart uses pseudo-terminals for logging. The Windows NT Linux subsystem, according to the Microsoft demo video, doesn't implement pseudo-terminals and returns ENOENT when a program attempts to obtain one.
Then there's the fact that the Windows NT Linux subsystem doesn't run Linux programs as the first process in the entire system. That honour goes, of course, to Windows NT's own Session Manager. Both systemd and upstart have "Am I process #1?" checks, and operate in a non-system mode if they aren't process #1.
Which brings us on to the fact that Windows NT already has a mechanism for launching daemons. It already has a Service Control Manager that supervises daemons and that talks LPC to control utilities. It already has a Session Manager that handles initialization, shutdown, and sessions. Ironically, it has had some of the things that are "new" in systemd for roughly a quarter of a century. (But some of those "new" things aren't even new in the Linux and Unix worlds, really.)
It's worth observing that the approach taken by the old Windows NT POSIX subsystem (the Interix-derived SFU/SFUA one) is to run daemons under Windows NT's own Service Control Manager. There is a small shim (psxrun.exe) for ensuring that the Service Manager could run and control the POSIX program, doco on what environment a POSIX program should expect when run under the Service Manager, and an Interix version of the service(1) command that understands Windows NT service management and how to speak to it.
It would be interesting to see how some of the daemontools family of service management toolsets -- such as nosh, runit, perp, daemontools-encore, and s6 -- fared on the Windows NT Linux subsystem. I suspect that one would trip over unexpected holes in the Windows NT Linux subsystem (like setuidgid not working because the underlying system calls return EPERM, perhaps). But I also suspect for several reasons that quite a lot would work. The daemontools family uses FIFOs and ordinary files as the control/status API; is composable and loosely coupled and so doesn't lock everything in to Linux-specific stuff (like specific files in /proc, /dev, or /sys) even if one tool in a toolset might need such stuff and permits that one tool to be replaced or otherwise worked around; and can do service management without demanding to be process #1.
So one could spin up svscan, or service-manager, or perpd, or runsvdir; stub out or comment out invocations of setuidgid or runuid with a dummy program if the Windows NT Linux subsystem didn't support that; similarly stub out or comment out invocations of jexec (for nosh service bundles that use BSD jails) and whatever of ionice, chrt, and numactl (for nosh service bundles that use those) don't work; and probably get quite far.
But the big deal would be spinning service management up outwith a Windows NT login session, so that daemons are actually daemonized. The old Windows NT POSIX subsystem actually has an init process (and an inetd) that can spin up other stuff. I strongly doubt, given the very clearly stated aims, that the new Windows NT Linux subsystem has (or will have) anything similar.