The problem is something that I didn't notice during image build; for some reason, the headers package gets the directory(s) wrong.

If you go into /lib/modules/ you will see that there are 4 directories, when there should only be 1.

You can remove all of them except for 4.14.50-kali-v7+

And then due to the headers issue, you want to make sure that the build symlink in there correctly points to
/usr/src/linux-headers-4.14.50-kali-v7/

So if the build symlink is incorrect, then do

cd /lib/modules/4.14.50-kali-v7+
rm build
ln -s /usr/src/linux-headers-4.14.50-kali-v7/ build

And then it should properly find the headers.

Because the headers for both armel and armhf are installed, it attempts to build the module for both kernels, and that is incorrect.

As you suggested, I removed extra directories from /lib/modules and made sure /lib/modules/4.14.50-kali-v7+/build was linked to /usr/src/linux-headers-4.14.50-kali-v7

Unfortunately the net result of 'apt-get install realtek-rtl88xxau-dkms' was similar:

Loading new realtek-rtl88xxau-5.2.20.2~20180812 DKMS files...
It is likely that 4.14.50-kali-v7+ belongs to a chroot's host
Building for 4.14.50-kali-v7+
Building initial module for 4.14.50-kali-v7+
Error! Bad return status for module build on kernel: 4.14.50-kali-v7+ (armv7l)
Consult /var/lib/dkms/realtek-rtl88xxau/5.2.20.2~20180812/build/make.log for more information.
dpkg: error processing package realtek-rtl88xxau-dkms (--configure):
installed realtek-rtl88xxau-dkms package post-installation script subprocess returned error exit status 10
Errors were encountered while processing:
realtek-rtl88xxau-dkms
E: Sub-process /usr/bin/dpkg returned an error code (1)

With a make.log containing:

DKMS make.log for realtek-rtl88xxau-5.2.20.2~20180812 for kernel 4.14.50-kali-v7+ (armv7l)
Mon Oct 8 21:42:56 EDT 2018
make ARCH=armv7l CROSS_COMPILE= -C /lib/modules/4.14.50-kali-v7+/build M=/var/lib/dkms/realtek-rtl88xxau/5.2.20.2~20180812/build modules
make[1]: Entering directory '/usr/src/linux-headers-4.14.50-kali-v7'
Makefile:638: arch/armv7l/Makefile: No such file or directory
make[1]: No rule to make target 'arch/armv7l/Makefile'. Stop.
make[1]: Leaving directory '/usr/src/linux-headers-4.14.50-kali-v7'
make: [Makefile:1928: modules] Error 2

ls confirms that /usr/src/linux-headers-4.14.50-kali-v7/arch does not contain armv7l:

root@kali:~# ls -l /usr/src/linux-headers-4.14.50-kali-v7/arch
total 152
-rw-r--r-- 1 root root 30151 Jul 15 22:03 Kconfig
drwxr-xr-x 9 root root 4096 Aug 6 16:31 alpha
drwxr-xr-x 13 root root 4096 Aug 6 16:31 arc
drwxr-xr-x 99 root root 4096 Aug 6 16:31 arm
drwxr-xr-x 11 root root 4096 Aug 6 16:31 arm64
drwxr-xr-x 17 root root 4096 Aug 6 16:31 blackfin
drwxr-xr-x 8 root root 4096 Aug 6 16:31 c6x
drwxr-xr-x 8 root root 4096 Aug 6 16:31 cris
drwxr-xr-x 8 root root 4096 Aug 6 16:31 frv
drwxr-xr-x 7 root root 4096 Aug 6 16:31 h8300
drwxr-xr-x 6 root root 4096 Aug 6 16:31 hexagon
drwxr-xr-x 12 root root 4096 Aug 6 16:31 ia64
drwxr-xr-x 9 root root 4096 Aug 6 16:31 m32r
drwxr-xr-x 24 root root 4096 Aug 6 16:31 m68k
drwxr-xr-x 9 root root 4096 Aug 6 16:31 metag
drwxr-xr-x 9 root root 4096 Aug 6 16:31 microblaze
drwxr-xr-x 50 root root 4096 Aug 6 16:31 mips
drwxr-xr-x 13 root root 4096 Aug 6 16:31 mn10300
drwxr-xr-x 8 root root 4096 Aug 6 16:31 nios2
drwxr-xr-x 7 root root 4096 Aug 6 16:31 openrisc
drwxr-xr-x 9 root root 4096 Aug 6 16:31 parisc
drwxr-xr-x 17 root root 4096 Aug 6 16:31 powerpc
drwxr-xr-x 16 root root 4096 Aug 6 16:31 s390
drwxr-xr-x 7 root root 4096 Aug 6 16:31 score
drwxr-xr-x 14 root root 4096 Aug 6 16:31 sh
drwxr-xr-x 13 root root 4096 Aug 6 16:31 sparc
drwxr-xr-x 8 root root 4096 Aug 6 16:31 tile
drwxr-xr-x 7 root root 4096 Aug 6 16:31 um
drwxr-xr-x 7 root root 4096 Aug 6 16:31 unicore32
drwxr-xr-x 26 root root 4096 Aug 6 16:31 x86
drwxr-xr-x 9 root root 4096 Aug 6 16:31 xtensa

I had a quick go at linking armv7l to arm and also to arm64 (in /usr/src/linux-headers-4.14.50-kali-v7/arch), which got it further, but in both cases it then went on to fail with compilation errors, so I presume that was not a valid strategy.

That will be an upstream issue actually, the arm architecture reports back armv4,5,6,7 but the kernel has all of them under arm (and arm64 is for 64bit kernels, we only support 32bit for the rpis currently.) unfortunately, those drivers are terrible (not the fault of the air rack developers but Realtek themselves) so you may have to dig in yourself to figure out what is going wrong with it.

I did recently purchase an 8812 device based on dragorn’s recommendation, so may try and figure to dig in, but for now, this is an upstream issue.

I would recommend opening an issue on their tracker, https://github.com/aircrack-my/rtl8812au

Sorry, phone autocorrect went nuts - https://github.com/aircrack-ng/rtl8812au

:)
OK, will do, thanks for the help.