Just FYI, even if the 68060 were microcoded *very few* microcomputer CPUs allow the microcode to be modified by the user. ("Writable Control Stores" were fairly common in old CISC mainframes and some Minicomputers, however.) Nearly all eight and sixteen-bit CPUs are fully microcoded, but to change anything in almost every possible instance you'd be looking at having to modify a mask ROM on the CPU die itself.
And yeah, I know Intel CPUs since the Pentium Pro can be loaded with runtime microcode patches, which is a fairly unique ability, but even in that case I don't think you could use that facility to, say, force a Pentium 4 CPU to recognize some hardware-specific instruction unique to the Pentium III series. Only Intel knows for sure (Intel's updates are encrypted and highly obfuscated to prevent them from being exploited or even accidentally loaded on the wrong CPU.), but the little research I've done seems to indicate that the Intel microcode table is essentially a breakpoint *after* the instruction decoder which allows a sequence of RISC-like "micro-ops" to be substituted for an existing operation sequence. (Usually the replacement string bypasses some hardware acceleration feature found to be buggy, thus trading off some performance for reliability.) Whether you could actually trap an "illegal" instruction and make it valid with a Microcode update *alone* on an an Intel CPU is something only they know, but it would probably be a non-trivial exercise.
In a purely theoretical sense I've wondered if it would be possible to modify a Transmeta VLIW CPU to run Motorola 68k code. In principle a Crusoe or Efficeon with appropriate code-morphing software could probably easily outperform *any* real 68k CPU, even the fastest Coldfires. Of course, Transmeta never released the tools or documentation you'd need to write your own code-morphing microcode so... that's that. We'll never know whether a 68k-morphing Efficeon would be able to outperform a conventional Intel or AMD CPU running a "normal" 68k emulator or not.