[AT&T, Rogers, Bell, Telus Samsung Galaxy S III] OnTheMF:
Well, I've solved it. After more effort than I care to admit to, I've found the cause of a lot of the grief with the network mode settings. I'll leave this info here in case someone else ever comes looking for it.

First off, it appears selecting "LTE only" wasn't working due to some sort of bug either with the radio baseband or with how some of the custom roms deal with the baseband. This bug was persistent across ROM reflashes because persistent data in the baseband remained. It appeared to have fixed itself when I flashed back to a stock rooted rom and did a factory reset. Other people have found this solution to work for other bizarre radio related issues, such as no LTE. Anyway, that fixed the LTE only selection.

In regards to the apparent disconnect between the list of preferred networks and what the radio was actually doing, as it turns out there is a mismatch. At some point in my search I downloaded the CM10.1 source and started digging around. I found in the ril directory the reference-ril.c file which describes the network modes:

static int net2modem[] = {
MDM_GSM | MDM_WCDMA, // 0 - GSM / WCDMA Pref
MDM_GSM, // 1 - GSM only
MDM_WCDMA, // 2 - WCDMA only
MDM_GSM | MDM_WCDMA, // 3 - GSM / WCDMA Auto
MDM_CDMA | MDM_EVDO, // 4 - CDMA / EvDo Auto
MDM_CDMA, // 5 - CDMA only
MDM_EVDO, // 6 - EvDo only
MDM_GSM | MDM_WCDMA | MDM_CDMA | MDM_EVDO, // 7 - GSM/WCDMA, CDMA, EvDo
MDM_LTE | MDM_CDMA | MDM_EVDO, // 8 - LTE, CDMA and EvDo
MDM_LTE | MDM_GSM | MDM_WCDMA, // 9 - LTE, GSM/WCDMA
MDM_LTE | MDM_CDMA | MDM_EVDO | MDM_GSM | MDM_WCDMA, // 10 - LTE, CDMA, EvDo, GSM/WCDMA
MDM_LTE, // 11 - LTE only
};

These correspond directly to the spinner selections in the phone info activity, which are:

private String[] mPreferredNetworkLabels = {
"WCDMA preferred",
"GSM only",
"WCDMA only",
"GSM auto (PRL)",
"CDMA auto (PRL)",
"CDMA only",
"EvDo only",
"GSM/CDMA auto (PRL)",
"LTE/CDMA auto (PRL)",
"LTE/GSM auto (PRL)",
"LTE/GSM/CDMA auto (PRL)",
"LTE only",
"Unknown"};

If you compare the two, you can see that the descriptions are not entirely accurate. In particular, many of the mode strings do not indicate they would select EVDO (even though the mask from reference-ril.c clearly shows they would). On devices which don't support EVDO, such as the i747, selecting these modes fail.

With the LTE only network mode now working, I see no need to implement the service mode band selection menu. With that said I did have a few solid strategies for doing it, if I decided to go that route. I peeked into the SecFactoryPhoneTest.apk a little bit, which is the service Samsung uses to communicate between the RIL and userspace java apps. It connects to a local socket named "Multiclient". I found this really bizarre because the telephony stack already connects to the RIL socket, and second the socket is typically named "rild". I believe Samsung has a custom implementation of rild (the linux userspace daemon which passes RIL requests to the kernel) which implements this extra "multiclient" socket. I could not find this socket on my AOSP based ROMs, so I assume it is a proprietary Samsung thing.

Instead of connecting directly to an RIL socket, you might be able to send the bytes associated with pulling up the band selection menu, and then blind sending the correct menu selections. The samsung service uses reflection to try and send RIL requests through the ITelephony interface (and then falls back on making a direct RIL connection). Here's how it does it:

Method localMethod = localITelephony.getClass().getDeclaredMethod("sendOemRilRequestRaw", new Class[] { [B.class, [B.class });

Now I think the sendOemRilRequestRaw method is another proprietary function, but a similar one exists in the AOSP RIL implementation which is invokeOemRilRequestRaw. Using the same technique you might be able to send raw bytes to the RIL without messing around with sockets.