The whole "single concern" analogy fell apart there. "View output: a Virtual DOM rendering of the model, and raw user input events" - it's the only component that does two things. Moreover, if this is just the virtual, unrendered DOM, where do the events come from?
DOM events are being delegated to Virtual DOM event handlers. This is what 'dom-delegator' does, it comes from mercury: https://github.com/Raynos/mercury/blob/master/docs/dom-deleg...
Still, the View doesn't "do" two things. It does just one: renders virtual elements. The virtual element output just happens to consist of two things: the element, and events coming from that element.
In tests where the View is isolated from the browser and from the Model-View-Intent cycle, virtual DOM events will actually not exist at all, because there is no user interacting with the view. Virtual DOM events only happen, and only make sense, when everything is plugged in and executing in the browser with user interaction.
The cool thing is that rendering is totally separate. Virtual dom? If that floats your boat, cool. You can just as easily bake Knockout into the mix and you'd be flying through implementation. It'd be both easy and flexible. Could probably componentise the UI very easily too. I dig it.