While doing this in some form seems not inherently a bad idea, one
  complicating factor is that people's preferences and setup for naming
  and keeping old kernels vary considerably.

A good point.  There is existing prior art, though, in that 'make
install' in a kernel build dir renames /netbsd to /onetbsd and
installs the new kernel as /netbsd (well, a bit more safely):

install-kernel-${MACHINE_NAME}:
        rm -f ${DESTDIR}/onetbsd
        ln ${DESTDIR}/netbsd ${DESTDIR}/onetbsd
        cp netbsd ${DESTDIR}/nnetbsd
        mv ${DESTDIR}/nnetbsd ${DESTDIR}/netbsd

I perhaps didn't express myself clearly, but I was thinking about
having the new target simply invoking the install target in the
compile directory.

  I personally keep each kernel as /netbsd.NNN (or netbsd.CONF.NNN for
  variant configs i might be testing), and then have symlinks for netbsd
  and netbsd.old and netbsd.test.  This seems not too unusual, but I've
  seen others do wildly different things.

Do you use the install target and override it, or just do things
manually?  I would expect that having an installkernel target would
not bother you, though, if you don't invoke it, and that this is
exactly parallel to the existing make install target in compile/FOO.
I'm not trying to be difficult, just trying to point out that my
suggestion wouldn't really make the current situation worse for people
that do things in their own way.

I use the install target, and when a kernel is known to work copy it
to kernel.ok, which I use as my fallback^2 if onetbsd doesn't work.

There is a minor overloading of = at the moment, too: install=/
specifies a DESTDIR, whereas releasekernel=FOO specifies a kernel
config.  So installkernel really should take two arguments, and I
suppose it doesn't really matter how they are encoded.