It's not actually grub which does this, but the initramfs. On Debian, the default initramfs implementation is the one inside the initramfs-tools package. What your initramfs does exactly to be able to mount the root filesystem can depend on many factors, including things like which packages are installed (packages can add hook scripts to extend the initramfs functionality) at the time when update-initramfs was last called, and how they were configured.
Since the problem appears to be that your mdraid devices aren't being rebuilt, I suspect that your mdadm package hasn't been configured right. Try to fix that first:
sudo dpkg-reconfigure mdadm
After that, the initramfs should be updated automatically.
If that doesn't fix it, and as part of your migration to software RAID you created a new filesystem, then it may be that your fstab has the UUID of the old filesystem, which now no longer matches the new filesystem. Check this:
grep $(blkid /dev/md0) /etc/fstab
If that produces no output, then edit /etc/fstab to replace the UUID specified there for the root device with the output of blkid /dev/md0, and run update-initramfs again.
Best Answer
I found the solution to this issue in the following thread titled: [SOLVED] CentOS 6 on GA-990FXA-UD5.
The solution involved removing the BIOS RAID metadata that apparently was part of a residual software RAID that the 40GB HDD must of been used in. Running this command in the CentOS 6.5 LiveCD in a terminal fixed it:
To which I replied "y".
Anaconda
This failure is a little unnerving since it occurs while running the Anaconda installer tool that's typically used by all the Redhat products (CentOS/Fedora/RHEL) and the failure is not graceful.
I'm not sure why, but Anaconda cannot deal with this situation itself, and it leaves you in a state where you can see the "verbose" debug output, which was far from helpful.
I saw no other way around the issue from within Anaconda.