efibootmgr is giving me the "system does not support efivars" when I boot from a Ubuntu USB stick.
This happens because you're booting from the USB stick using the legacy BIOS style, so UEFI's compatibility support module will disable the UEFI run-time interface that would be used to access the boot variables. If you can boot the USB stick in native UEFI mode, then efibootmgr will work. If the firmware boot settings include a choice whether UEFI or legacy boot methods are tried first, try switching it to "UEFI first" mode while booting from the stick.
With a legacy MBR GRUB2, you can only boot operating systems that are bootable with the legacy MBR style. In order to chain to an operating system that's been installed to boot using native UEFI, you'll need an UEFI version of GRUB2.
The problem in transplanting an UEFI GRUB from one distribution to another is that different distributions set it up in slightly different ways: for example, Debian used to plant a very minimal grub.efi to ESP with embedded instructions to read further GRUB modules and the configuration file from another filesystem specified at the GRUB installation time (typically the filesystem that contains the /boot directory).
The problem with this approach is that Secure Boot makes this impossible if enabled: all executable code loaded must be signed, and since GRUB modules are not using the same binary file format as the standard UEFI binaries, they cannot be signed in a way that would be recognizable as such for the UEFI firmware.
RedHat-derived distributions, on the other hand, tend to embed all the necessary GRUB modules into the main grubx64.efi binary, which can then be successfully loaded in one operation by the Secure Boot shim.efi. The GRUB configuration file is also placed in the ESP filesystem, typically reflecting the naming of the main UEFI GRUB binary, i.e. if the binary is renamed to foo.efi it will look for foo.cfg in the same directory.
Knowing this, you could just make sure Secure Boot is disabled, grab the grub.efi binary from a RedHat/CentOS/Fedora installation media, write it a minimal configuration file manually, place them into your ESP (perhaps as \EFI\boot\bootx64.efi and \EFI\boot\bootx64.cfg, so UEFI should pick them up automatically with no need of UEFI variables) and boot once. Then you could see if the GRUB configuration file generated by TinyCore's native GRUB configuration generator is compatible with that version of GRUB, and either replace the simplified configuration file with a real one, or replace the transplanted version of GRUB with TinyCore's preferred version of UEFI GRUB.
If you want to boot TinyCore's vmlinuz directly from the UEFI firmware, the kernel needs to be compiled with CONFIG_EFI_STUB=y, and then you'll need to figure out what to do with the boot parameters and the initramfs file. I made such a set-up once, by configuring the boot options into UEFI boot variable. Without a bootloader, you probably won't have any way to change the boot parameters at boot time, so you'd better generate several UEFI boot variable settings ahead of time with different boot parameters, so that you'll have a way to access the system if something goes wrong with a kernel update for example.
(If your firmware-level UEFI boot options include a way to boot into UEFI Shell, it can be very useful in setting a "bootloaderless" UEFI-bootable installation.)
The UUIDs used in UEFI boot variables can be discovered by running the blkid command. GRUB uses the filesystem UUID (= the UUID= field), while the UEFI boot variables use the partition's unique UUID (= the PARTUUID= field).
