Actual code generation at the driver level seems utterly wrong.
"Utterly wrong" is a pretty black-and-white judgement. A JIT in the kernel has costs and benefits. You could as easily say that the ability to load modules dynamically into the kernel is "utterly wrong," since it opens up a code-injection vector that makes rootkits and other malware much easier to write. In some ways dynamically-loadable modules could be seen as even more risky than a JIT, because a JIT can only generate a subset of all possible machine code. It would be pretty hard to write a rootkit as a Berkeley Packet Filter program.
However, it wouldn't be impossible. I am quite sure (although I don't have a proof) that the BPF bytecode can be made turing complete, so an arbitrary program (maybe a rootkit, much more likely patches to a few kernel structures) could be implemented in it. Examples of things that are very unintendedly turing complete include HTML5 without JS(the clicky rule 110), ELF relocations (you can write a program to be interpreted by the loader in a few symbols and relocations without changing code, see elf-bf-tools on GitHub) and the Intel interrupt handling mechanism(unreleased, see talk at 29c3).
elf-bf-tools is an impressive hack, thanks for the link! To add to your list, you might want to mention that simply parsing C++ is turing-complete; see http://yosefk.com/c++fqa/web-vs-c++.html#misfeature-3 . The short of it is that you have to perform full template instantiation in some cases just to parse code that uses those templates!
As to your point about /dev/kmem, to me that is just another argument against the idea of banning JITs from the kernel. There are already lots of vectors for getting attack payloads into the kernel; the JIT angle only helps an attack if you somehow can make the kernel jump to a specified address but don't have root.
"Utterly wrong" is a pretty black-and-white judgement. A JIT in the kernel has costs and benefits. You could as easily say that the ability to load modules dynamically into the kernel is "utterly wrong," since it opens up a code-injection vector that makes rootkits and other malware much easier to write. In some ways dynamically-loadable modules could be seen as even more risky than a JIT, because a JIT can only generate a subset of all possible machine code. It would be pretty hard to write a rootkit as a Berkeley Packet Filter program.