It's quite possible that the oom killer is involved, but it is clearly not entirely the oom killer's doing: at the very least there has to be a process protected from the oom killer which is watching for oom and triggering a reboot. More likely there is a trivial kernel hack to autoreboot on oom.
I had what a believe is a framework restart on my Paperwhite a couple of days ago, while using X-Ray -- actually laughing at it, this particular book had mixed up three characters into one and missed half the characters in the book out, very useful. I got the reboot screen with the moving progress bar immediately. The no-progress-bar reboot screen (a framebuffer screen covering the Linux kernel's boot messages) which appears before that in a true reboot never appeared. Thus my conclusion that this was the framework and possibly X server restarting. (The X server is never oom-killed -- on hardware with conventional graphics cards that has a tendency to be disastrous and can even lock up the PCI bus and require a power-off! -- so whatever shut that down cannot have been the oom killer.)
As for what can be oom killed (assuming the oom killer is enabled), this changes across kernel versions. Root processes get a bonus against being oom-killed, but if everything is running as root this is irrelevant. They are still oom-killable. init (PID 1) cannot be oom killed. Kernel threads cannot be oom killed. Processes that mark themselves (via /proc/self/oom_adj/oom_score_adj) as un-oom-killable cannot be oom killed. In many kernels, tasks engaging in direct hardware access (e.g. the X server) cannot be oom killed. Everything else is fair game.