No, doing a .zip download from the web interface wouldn’t work for me, as various directories are far larger than the bounds set for .zip download.
That aside, I found that, yes, the directory creation does in fact work.
And as far as OP’s issue, where I was running into something similar, I found it to be the result of a permissions “thing” on the storage that the client had access to.
I first tried to tell the urbackup server to start up as the root user using the config at /etc/default/urbackupsrv and within that file setting this part like so:
... (rest of the config file up here...excluded)
#User the urbackupsrv process runs as
USER="root"
Then restarting the server via the normal process.
However, that still started urbackup server running as the urbackup user. Arrrgh!
Eventually I found that I have to go the hardline route, and explicitly tell the server’s execultable to start and run as the root user like so:
urbackupsrv run -u root
That, finally, resulted in the ability to kick-off restores, from the web UI, that ran as expected and created the expected folders while restoring files successfully. 
I don’t know why urbackupsrv isn’t respecting the config file, in this regard. However, consideration/discussion of this point I’ll leave to a totally different thread. For this thread’s topic, I at least solved it for my particular scenario. I hope that it will help some poor soul that comes across a similar issue. 