Those two packages did the trick.  Also, it turns out they were compiled alongside live-boot and live-config -- they were residing in the same directory as the compiled debs.  So, backporting live-boot/config built them, and all I had to do was install them.  Shame on me for not checking the other debs that were originally created and should have been installed lol.

Problem solved -- even works with the newest liquorix kernel.

I can confirm that your basic procedure works. I have a new install of desktop-live on my hard drive, so I chrooted into it and started making isos. I had to do a little more, because it's an encrypted install, (remove conf/conf.d/cryptroot from initrd). Installed 4.15 from backports, did not remove 4.9, made another snapshot and it boots 4.15 normally.

Oh yeah, I had to remove intel-microcode before I could unpack and repack the initrd.

And I didn't backport anything. Just running ascii and chrooting into another ascii install. Maybe something else in jessie needs to be upgraded for this to work.

still complaining about ehci-orion not being in modules.dep

It always says that when there's a problem.

Why does it give that particular message?  It seems way too vague.

The folder conf contains two files and one folder:
arch.conf contains one line: DPKG_ARCH=amd64
conf.d is completely empty.
I uploaded initramfs.conf to pastebin.  Not really sure what any issue would be...
https://pastebin.com/ChjY6Kzm

Edit: I compared it with the jessie (3.16) initrd.img.  The results were exactly the same, including the contents of conf.d and initramfs.conf.

still complaining about ehci-orion not being in modules.dep

It always says that when there's a problem. Don't chase that ghost. What was in conf/conf.d/ in the initrd? That's usually where the problem is.

Sadly, it's still complaining about ehci-orion not being in modules.dep.  I'm not sure if this can/should be patched or if it's available in some other package.
https://ibb.co/h9o2yn
The 3.16 modules.dep file doesn't contain ehci-orion at all, either, but it doesn't err.  This seems to be an issue that keeps popping up with the 4.9+ kernels.

There's no more aufs in the kernel (4.9 or 4.14)

That's the gist I got :\

Thanks, I noticed that jessie's versions are considerably older, live-config in particular.  I'll try the live-build backport just in case.  If it still fails, and manually backporting isn't worth it, I'll just consider upgrading to ascii sooner than anticipated.

There is no union=* in the boot command.  A few sites suggested to try union=overlay, which I tried, but that failed.

You may need a newer version of live-boot* and live-config*. 20170112 should work (works for me) and is in ascii.
If you have a union=aufs (or union=anything) in your boot command, remove it.

The fix in that bug report was for live-build, which is not used here.

where config/chroot is an ambiguous directory, which is unhelpful.

I find this weird because I can run the backported kernel on my build system (devuan jessie) just fine.

cp /boot/initrd.img-4.14-whatever .
mkdir extracted
cd extracted
zcat ../initrd.img-blah  | cpio -i

Then examine the files in conf/conf.d/. Look for something that has a wrong uuid or device name.

When you install a newer kernel, it takes over the symlinks, /vmlinuz and /initrd.img, which will be used by refractasnapshot. It copies them to  work/iso/live. The usual procedure is to install the new kernel first, then remove the old kernel. There are two reasons for doing it in this order: 1. Usually, the old kernel is running when you do this, so you can't remove it until you boot into the new kernel. 2. In case the new kenel doesn't work, you can still boot the old one. Since you're doing this in a chroot, it shouldn't matter.

If you want more than one kernel in the iso, you need to copy it to the same place with a different name, and you need to make a boot entry for it. Make sure you have set save_work=yes in the config file.

what do you mean by "installed a live build from chroot"

Sorry if that was unclear.  I debootstrapped a system and develop it through chroot; that includes running refractasnapshot within the chroot environment, and accessing the iso from the host filesystem later on.  I don't believe this approach uses swap in the way you inquired below.  Also, nothing is encrypted.

With the normal jessie kernel, the iso produced works as expected, whether I'm entering the live environment through a virtual machine (qemu), or dd-ing the iso onto a removable drive (usb).  Actually, you would know, since you tested it for me.
https://dev1galaxy.org/viewtopic.php?pid=8241#p8241

One thing I forgot to mention in the original post is that I'm trying to replace the kernel altogether, although I do intend to experiment with a version that includes two kernels in the future.  For now, I'm inquiring about replacing the jessie kernel with a backported one.

Using the procedures in the original post, I've tried:
a. removing the jessie kernel and then installing the backported one, and
b. installing the backported one and then removing the jessie
Both produce the same kernel panic message.  What I also find weird is that, no matter what, when I uninstall the bpo and re-install jessie's, it goes back to working as expected.  I did not attempt a snapshot which included both jessie's kernel and the bpo.

Researching the panic led to ambiguous results, not to mention the screen cuts off because it's something like a 640x480 resolution.  My gut tells me that this is an initrd error, but I've never encountered an issue like this before.  I've even manually ran the initrd and grub update commands after the bpo kernel is installed, even though it runs those during installation anyway.

There's something wrong in the initrd. Is this installed on a removable drive? ? Or from a snapshot that was made on a system that has a swap partition or an encrypted partition?

Edit: If you make a snapshot of a system that has more than one kernel, you may need to copy the extra kernel and initrd to $work_dir/iso/live/, and if you want both kernels available in the live iso, they must be named differently and you must create boot menu entries for the extra kernel.

Procedures (all as root):

apt-get -t jessie-backports install linux-image-amd64
(update-initramfs loads automatically)
(update-grub runs automatically)
refractasnapshot

SOLUTION: install/backport the ascii+ versions of live-boot live-config live-config-sysvinit live-boot-initramfs-tools.  Backporting/installing the former two will also backport/install the latter.  For convenience, I've uploaded them to the crunkbong github page here, but I don't intend to maintain it after ascii reaches stable.