I quickly looked at the source code for that ClosedCaptionImporter. Apparently, there's a (new?) 'cdat' atom that contains the actual CEA-608 bytes used for Closed Captions. An .scc file is just a text file that contains those byte values (as text) along with some time codes. The importer reads the text files, converts the text to bytes, and uses QuickTime calls to insert those bytes into a Closed Caption Track, which you can see in QuickTime Pro with Show Movie Properties.
(The ReadMe.rtf for the importer contains a link to a site with SCC tools, and from there is a link to details on the CEA-608 byte codes:
http://www.geocities.com/mcpoodle43/SCCTOOLS/DOCS/SCCFORMAT.HTML )
QuickTime Player and iTunes will read those bytes, and act like a TV does: interpret those codes to display text. (Be sure to have "Show closed captioning when available" selected in Preferences before opening the file, otherwise it doesn't seem to work.) So great, what's the actual workflow so this is usable?
There may be free tools to convert a text script to SCC format. For example, on that first tools page, there's an example of the format supported by PAS2SCC, which is at least human-readable. So somehow you get your captions into SCC, you can use the importer to create the CC track, and you can use QTPro to copy the track into the movie. I'm fuzzy as to whether the 'cdat' has to be in a .mov, and not in a .m4v, and whether that's valid for a podcast.
Otherwise, you may need to use the QuickTime API to modify the track directly, and looking at that source code, it's not crazy difficult. You might even be able to make a complete app out of it, so that you can type in text, and have it do the CEA-608 encoding. And then if you charge less than the $9000 I saw for some other similar product, you might sell a few.