What does full virtualization mean in this context?
I guess a more general approach may be helpful.
First off, as soon as virtualization leaves the topic of the (core) CPU, anything becomes machine and implementation specific - so it's not only relying on the CPU itself. Further, even such a virtualization does usually need an hypervisor, another OS, providing real world services to these - and being able to emulate next to all external resources. More often than not, such a 'Guest OS' does provide hypervisor specific drivers in addition, avoiding extreme performance impacts.
At the heart it's about the 'picture' a 'bare metal' (*1) application gets of the machine it's running on one side, and what kind of hardware access the guest OS does expect.
Despite facing the danger promised, I would like to cite the /360 as a more simple example to display this fact. Already from the start I/O was quite formalized as an interface to an IO processor (*2). There was a limited set on instructions to start an I/O operation, check for status and cancel them if necessary, but no other way to communicate with the outside. These high level structures made it easy to virtualize I/O, after memory and CPU were done (*3)
For micros (and minis) the task was a way more complex one as their low level I/O. Low level was not a huge pile of separate instructions manipulation I/O addresses that needed to be interpreted in a coherent way.
With all that said and for 8 bit microprocessors I'd give a 6809 in a system with a 6829 MMU (and maybe a 6828 PIC (Priority Interrupt Controller)) a head-start in 1978 (*4). Depending on hardware and OS structure this would work out fine.
In reality the issue is as so often not about technology, but the need for solutions. With micros there was no use case. Where mainframes focused, during the 80s and 90s, quite a lot on machine virtualization to consolidate installations, micros spread just as they were. 'Lesser' ways of virtualization did provide everything to satisfy the need for executing parallel applications and services in a sufficiently separated way. Much like with mainframes before, adding more CPUs was more important than to make virtual machines share a real one.
During the 90s micros had taken on more and more roles as servers, spread out in companies, 'infecting' every corner. This resulted in high pressure to consolidate. Servers where moved to computing centres and migrated into rack mount machines. While many of these applications did need their custom environment, they did use only small portions of a machine's resources. At the same time the early 2000s brought new highly partitioned applications with services in prior unimaginable numbers for high throughput web servers, search engines and alike. In combination this created a surge for virtualization, a need CPU manufacturer satisfied with new models. First with server processors, where the use case originated, in the long run for everyone.
The rest is history and I'd rather shut up and point to Stephen Kitt's detailed answer.
... Aaaargh ... I can't.
The 80386 did offer a 8086 VM mode that enabled hosting of multiple instances of its predecessor. The important part here is that it not only restricted access to 'unknown' register, and offered separate memory spaces but also allowed to trap access to (marked) memory and instructions like IN and OUT. As a result a 386 hypervisor could run multiple virtual 8086 instances, alas not emulating the PC running on, but any 8086 machine.
Something not uncommon in other families of CPUs, where new models not only offered (some) compatibility, but also full emulation - as it was called back then. Constructions like a /370 running a virtual /360 running a virtual 1401 where not unheard of.
*1 - Term chosen in lieu of any better. Meaning is that an application that can act as if running on the same (or similar) machine as if there was no virtualization.
*2 - Much like Intel envisioned for the x86 family with the 8089 I/O-Processor
*3 - Another great example how benefiting clean abstraction layers are in the long run.
*4 - IIRC it may as well have worked already with 6800+6829, but I'm unsure abut the introduction date of the 6829. It was available when the 6809 was introduced.