[X Style (Pure) Q&A, Help & Troubleshooting] TheLynxy:
I am having this exact same issue. Unlocked bootloader, flashed TWRP, and rooted.

I go to encrypt the phone, the Android guy appears for 1-2 seconds, then it gets stuck on the blue Motorola "M" logo. I left it this way for 7 hours before giving up.

On a MXPE with 64GB internal storage. No SIM or sdcard inserted. Performed a factory reset and immediately tried again, same result. Tried it again using adb logging, when it hangs on the "M" logo I get this:

E/Cryptfs ( 398): Bad magic for real block device /dev/block/bootdevice/by-name/metadata
D/Cryptfs ( 398): Just asked init to shut down class main
I/ServiceManager( 397): service '$WHATEVER_PROCESS_HERE' died

Followed by this, repeatedly forever:

I/ServiceManager( 8687): Waiting for service media.audio_flinger...
W/AudioSystem( 8687): AudioFlinger not published, waiting...

Ok, so I guess I'll stop the service:

am force-stop media.audio_flinger

That reports something about package manager isn't running. Probably because it shut everything down in order to start encrypting. So I restart, then right before I press the final "Encrypt" button I run the force-stop command. It appears to work, but after pressing the button the logcat is spitting out the same errors as before.

Huh, ok, so I'll just kill whatever processes are related to the audio flinger.

kill $PID_HERE

Tried it with a few different processes, each time restarting the whole encryption process before trying to kill a different process. Killing some would result in the screen going black. Under no circumstance did the encryption process move forward, if anything it made matters worse (I won't bother putting the logcat here).

Ok then, I'll try just doing the encryption using adb, so I run the command using su:

/system/bin/vdc cryptfs enablecrypto inplace PASSWORD

It returns without error, but nothing happens on the phone. Take a look at the logcat:

W/vdc ( 7808): type=1400 audit(0.0:14): avc: denied { read write } for uid=0 path="/dev/pts/2" dev="devpts" ino=5 scontext=u:r:vdc:s0 tcontext=u:object_r:devpts:s0 tclass=chr_file permissive=0
W/vdc ( 7808): type=1400 audit(0.0:15): avc: denied { read write } for uid=0 path="/dev/pts/2" dev="devpts" ino=5 scontext=u:r:vdc:s0 tcontext=u:object_r:devpts:s0 tclass=chr_file permissive=0
W/vdc ( 7808): type=1400 audit(0.0:16): avc: denied { read write } for uid=0 path="/dev/pts/2" dev="devpts" ino=5 scontext=u:r:vdc:s0 tcontext=u:object_r:devpts:s0 tclass=chr_file permissive=0
W/vdc ( 7808): type=1400 audit(0.0:17): avc: denied { read write } for uid=0 path="/dev/pts/2" dev="devpts" ino=5 scontext=u:r:vdc:s0 tcontext=u:object_r:devpts:s0 tclass=chr_file permissive=0
W/vdc ( 7808): type=1400 audit(0.0:18): avc: denied { read write } for uid=0 path="/dev/pts/1" dev="devpts" ino=4 scontext=u:r:vdc:s0 tcontext=u:object_r:devpts:s0 tclass=chr_file permissive=0

Ok... I'll try using TWRP to completely recreate the data partition (including internal storage). It fails with error "unknown MTP status 1". So I use TWRP to change the partition type of data to F2FS (it was already F2FS), and that appears to work just fine (did it remake it? no idea). Still no dice with encryption.

I've read online that perhaps the filesystem is overlapping the necessary 16KB at the end of the partition, so I try to run the command to check filesystem info (tune2fs) but it complains of a bad superblock. Frankly I have no idea how the data partition is being mounted. The "userdata" partition is /dev/block/mmcblk0p47 which has the total size equal to /dev/block/mmcblk0, even though there are a 46 other partitions on mmcblk0, each taking up their own space. An example is /dev/block/mmcblk0p46 (system) is about 6GB total. What the hell? How can 6GB + 62GB = 62GB? To add further confusion, it also mounts /sdcard using mmcblk0p47 (data) even though no sdcard is in the device. So I have no idea how this mystical mmcblk047 partition is working. Any insight on this would be very helpful.

A phone without encryption is useless to me. I am really hoping I can figure this out by October 13th, otherwise I'll have to return it :(.

UPDATE:

Big shoutout to rOOb85 from Reddit (see this thread) for explaining a process that works. Apparently being rooted causes this. The solution is to do a

FULL UNROOT

within SuperSU (disabling superuser is not enough).