For the last couple years, I was basically the primary developer of the Mozy backup client for Mac. I worked primarily on the background process that actually identifies and uploads the files you've selected, and less on the user interface, but I'm still quite familiar with the code in question. I believe this makes me one of the most qualified people in the world to answer your question.
On a UNIX-based system such as OS X, information about a filesystem ultimately comes from the statfs(2) system call. One of the pieces of information this call can return is called
f_mntfromname. This "mount from name" is basically the name of the raw device where the mounted disk originated. For physical volumes, it will probably look something like
/dev/disk0s2. For an AFP mount, it looks something like this:
afp_3gfD0q3eeRWD4jJmgS0DVWMM-1.2e000004. For a SMB share, it's something like this:
//bjhomer@macbook-f2a0b3/Some%20User's%20Public%20Folder. Anyway, the point is that in order to determine whether a file is on a network share or not, Mozy checks whether a file's filesystem was mounted from somewhere inside
/dev/, which is where all physically-attached devices live.
Unfortunately for you,
/dev/ is owned by the kernel, and as such not susceptible to simple tricks like a symlink. You'd probably have to resort to a kernel extension (kext) that mimiced the contents of your remotely mounted volume as if it were a locally-mounted volume. I'm not a kext expert, so I'm not even really sure if that's technically feasible. And remember, since Mozy can start a backup at any time, your kext would need to make sure the volume is there at all times, handling any network glitches or the unavailability of the remote volume gracefully. (Any errors are likely to cause a kernel panic.) And you'll need to make sure that the simulated volume is mounted just like a normal volume and can handle all the system calls correctly. It's probably possible to do all of this, but frankly, it seems like a lot of work for very little benefit.
All that being said, it's hard to bet against the creativity of the internet. So if someone comes along and thinks of a good way to do it, all the better for you. But know that a good deal of thought went into the design of this particular behavior, and I don't anticipate a simple workaround. Of course, now that Mozy has moved away from their unlimited storage plans, one could argue that continuing to limit the availability of network backups to MozyPro customers seems odd. I'd agree with you. Maybe this limitation will be removed some day, but in the meantime, this is what we've got.
(For the record, I no longer work at Mozy; it's possible that the implementation of this behavior has changed since I left. I would doubt it, but it is possible.)