Ok, I think I've got this figured out on my setup. Like shawnj, I also had > 35 databases per LUN. However, it does NOT seem that this is the cause of the problem in my case (though I am aware that it is not a recommended configuration). The production volumes in question are snapmirrored to a remote location; I then created another set of volumes and snapmirrors to replicate this to a new set of volumes so that I could test without interfering with the production snapmirror destination volumes.
In testing, I created an additional set of volumes/LUNs in order to split up the databases so that I had < 35 databases per LUN. The databases I moved to new LUNs backed up without issue and allowed me to restore without issue. However, the databases that I left on the original set of LUNs continued to give a time parsing error when attempting to restore from the backup set. Looking closer at the databases on these LUNs, I realized that when I removed backups of Sharepoint databases, the restore worked fine (as long as no prior snaps existed that contained the Sharepoint databases). Prior to this, it hadn't clicked for me that this server was indeed running Sharepoint (as a component of Team Foundation Server), as it's at a remote site and I don't frequently have my hands on it. We do not have SMMOSS.
Having no prior exposure to SMMOSS helped in overlooking this also. Well, this was something that had slipped by us and our consultants at the time we installed our filers. SMMOSS product documentation indicates that SMMOSS is extremely critical in order to successfully restore Sharepoint databases. As soon as I re-included these WSS databases in the SMSQL backups, the time parsing error/SMSQL crashing returned. As soon as I removed them and the associated snapshots again, the errors stopped.
So, in order to resolve this on the production end, I eliminated all WSS databases from the SMSQL backup job. Once I had a few days worth of snaps with this backup config, I purged all old snapshots that had selected the WSS databases for backup. Immediately after doing so, I was/am able to get into the SMSQL restore wizard without any time parsing error dialogs and without the SMSQL mmc crashing. As long as this holds up, I'll FINALLY be able to close the case that I've had open on this issue for the past 3 months.
So, in my case, this issue had nothing to do with exceeding the limit of the recommended databases per LUN (though restructuring the databases so that we keep to this limit is in the works). Turns out it was something much more straightforward (and something I should have picked up on earlier) - that SMMOSS needs to be used in order to properly restore databases where the LUN contains WSS databases. SMSQL will back up these databases without any problem, but the problems start when attempting to restore any databases that are included on this backup set. As we do not have a license for SMMOSS, I have not been able to test this as a resolution to the problem, but I believe that it is a safe assumption at this point. We'll be backing up the Sharepoint data via the stdadm tool for the time being until we see if we can evaluate the SMMOSS product.
