To make a program where the code -- not the data! -- exceeds 64K, it seems to me that the obvious approach would be to pull out some code into a separate module -- where nothing within the module calls anything outside the module -- and convert that module into a LibLoad-compatible library; then repeat as necessary until you're down to <64K outside the libraries. Right? There's not an easier way or a tool that I'm not aware of?

The toolchain already does this for you. You can either use the makefile compression option to compress your program, or it will automatically split your program into multiple appvars to allow you to exceed the 64K size. You don't need to do anything else.

As for the automatic split, I tried loading the resulting three files (one .8xp and two .8xv) into CEmu via the usual command line --send option. I checked calculator memory to confirm they were on the calculator. I tried running the .8xp when the .8xv files were in the archive (their default location), and I tried un-archiving them. Regardless of what I did, whenever I ran the .8xp the calculator gave me an out-of-memory error. Is there something different I need to do in loading the files into CEmu?

Ah, but the 8xp-auto-decompress option works beautifully for me with almost 50% compression, so the auto-split issue is moot until I'm nearing 128K. Thank you!

Programs get copied into RAM when they are run. The split is probably working fine, it's that there isn't enough memory to either decompress the program or load the libraries the program needs after the program itself is already loaded into RAM.
A lot of the time, you can store data in an archived appvar so that you don't have to copy it into RAM. For graphical data, convimg has convert options for that, and for other types of data you can use either os_GetAppVarData or ti_GetDataPtr to get a read-only pointer to the contents of an archived appvar.

The CE still has only 150KiB of memory that a program can use, and using all the libraries takes up ~17KiB of that. So you really only have 133 KiB of usable space in the end - and splitting an already compressed program generally means you exceed that limit almost every time. Splitting + compression is only good if your compression doesn't provide much.

To keep things simple, I took the SDK's hello_world and bloated it to ~70K non-compressed with lots of long strings. Split (without any compression), it failed. Compressed, it worked. That's the same outcome I get with my actual program at ~65K non-compressed.

You might just need to update your convbin version, I think it was recently fixed. Try this: https://github.com/mateoconlechuga/convbin/suites/5762838934/artifacts/191632106