Sun workstations did not use the dual 68000 approach to handle VM. The problem with the 68000 was that it didn't save enough information on the stack when an exception occurred (e.g. a page fault), so a faulting instruction could not be recovered/re-executed in all cases.
Sun solved this by using "harmless" instructions such as "tst" that did non have to be recovered in case of a page fault. The OS could then kick in, load the contents to memory and just skip the failed instruction. This required changes to the compiler, e.g. when creating a new stack frame that would have required to extend the stack size. For paging, this approach would cause significant overhead. However, the first versions of SunOS which ran on the Sun 1 workstations were based on 7th Edition Unix and used only swapping.
The 68010, used in the Sun-2 workstation, fixed the restarting problem by saving sufficient state to the stack, so SunOS could switch to an early BSD release as its basis.
AFAIK, the dual 68000 approach was used by early Apollo workstations instead. The way I understand it is that the second processor was idling until a page fault occurred. The 68000 has an asynchronous bus which requires an explicit acknowledge (/DTACK) to indicate that data (e.g. from slow memory) has arrived. This feature was used by the Apollos - the second 68k would kick in while /DTACK on the first 68k was deasserted, handle the required virtual memory operations, and then indicated that the first CPU can continue working. So here, no bus error was indicated (which would have caused the restarting problem), but the virtual memory behaved like a very slow physical memory. Apollos were able to perform remote memory accesses to other machines over the TokenRing interface (which was about as fast as memory accesses - 12 Mbit/s IIRC), so this feature was much more useful for DomainOS than for early Unix systems.