The kvm modules are a relatively thin layer to the hardware virtualization features. Note that kvm is not in and of itself a virtualization solution, just the kernel interface, it needs user-space host, like qemu .

The vboxdrv modules is to Virtualbox what the kvm module is to qemu. It also have several ancillary modules for networking: vboxnetadp and vboxnetflt. In theory, virtualbox COULD use KVM instead of it own module, but it doesn't (doubt it'll ever happen, but would be nice, as vboxdrv inspired a new taint flag: TAINT_OOT_MODULE)

Virtualbox is oriented toward virtualizing desktop environment as opposed to servers - but qemu/kvm has come a long way with things liek virtio, spice, and libvirt. However qemu/kvm/spice does not (yet) support host accelerated video, while VirtualBox does.

Another question about the orientation:
I guess it is more of feature development priority, not about the design?
I hope there's nothing like "qemu's design is for server only, not appropriate for desktop, VirtualBox is specially designed for desktop usage".

There no inherent reason why virtualbox can't be used for server usage, or qemu/kvm for desktop usage. Virtualbox is developed more of a "turn-key" solution to desktop virtualization, whereas qemu is more piecewise: qemu handles instruction and hardware emulation; kvm handles the virtualization acceleration; libvirt the configuration, management and user interface; virtio provides efficient guest/host I/O; and spice the video, input and host integration.

When virtualbox was intially release, qemu-kvm was just a fork of qemu, spice didn't exist, virtio was in its infancy and libvirt was still very young.