After another round of debugging this weekend, and googling, I managed to make some progress on this. Here's a quick technical examination; The initial issue is caused by a change on old ARM ABI, and new ARM ABI with respect to the handling of floating point operations. Without going into too much detail, the main issue came from the behavior of OABI ARM when using the FPA API; although ARM is traditionally a little endian architecture (with a handful of big-endian systems existing), in OABI ARM, the FPU (or FPU emulation) always took big-endian formatted doubles vs. little-endian doubles; any application which did bitwise operations on doubles needed to be aware of this and treat any doubles as big-endian while handling any non-FPU operation as little-endian. On EABI systems which mandate the VFP FPU format, all doubles are little-endian; newer versions of thunderbird and firefox have been properly patched to handle this, but thunderbird lacked the necessary change.

I was tipped off to this quirk in OABI ARM by http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=215067, which shows that NSPR segfaults if you try to pass very large numbers into it. A look at the backtrace reveals this happens in in the Javascript library; specifically:

#3 0x40073aac in js_NumberToString (cx=0x783f8, d=2147500034) at jsnum.c:724
 
and the end result can be seen in:

#2 0x4004b738 in JS_dtostr (buffer=0xbe9a5846 "Ã@\020\204\a",
    bufferSize=621765855, mode=DTOSTR_STANDARD, precision=0,
    d=8.2265532824141687e-308) at jsdtoa.c:2493

(this function coverts a double to a string, with d going in being close to the max. size of doubles on the ARM architecture).

The value is then passed into NSPR, which tries to use memory more memory than its allocated, and promptly segfaults (a more indepth explination of this behavior is in the original Debian bug). Loic's patch corrects a different behavior in NSPR that prevents mult()/Balloc() from working when using NSPR's user-land thread emulation, and not the system pthreads library; configure output suggests we do indeed use pthreads vs. NSPR's emulation. A couple of grep's later, and I found the necessary preprocessor macro's to change to force LITTLE_ENDIAN behavior in libjzmoz. The upshot is that the import wizard now runs (although it comes up with the window very large), and then thunderbird segfaults again, this time in fontconfig (the backtrace is incomplete, I'll post a more complete one later).

As it stands, I need to clean up my patch and source tree, so I'll post my current debdiff once I do that so others can continue to build off the work I've started. I'm hoping the current segfault is simply a side-effect from a non-clean build-environment.

My current backtrace:
(gdb) bt
#0  FcPatternObjectAddWithBinding (p=0x0, object=1, value=
        {type = 3439344, u = {s = 0x1 <Address 0x1 out of bounds>, i = 1, b = 1, d = 2.121995791459338e-314, m = 0x1, c = 0x1, f = 0x1, l = 0x1}}, binding=390632, append=1) at fcpat.c:476
#1  0x40a37230 in FcPatternObjectAdd (p=0x0, object=1, value=
        {type = 3439344, u = {s = 0x1 <Address 0x1 out of bounds>, i = 1, b = 1, d = 495.00000000000006, m = 0x1, c = 0x1, f = 0x1, l = 0x1}}, append=3) at fcpat.c:545
#2  0x40a37310 in FcPatternObjectAddString (p=0x0, object=1, s=<value optimized out>)
    at fcpat.c:664
#3  0x407c7a30 in ?? () from /usr/lib/vfp/libpangoft2-1.0.so.0
#4  0x4096e5cc in pango_font_map_load_fontset () from /usr/lib/vfp/libpango-1.0.so.0
#5  0x4096c514 in ?? () from /usr/lib/vfp/libpango-1.0.so.0
#6  0x4096cb4c in pango_itemize_with_base_dir () from /usr/lib/vfp/libpango-1.0.so.0
#7  0x40974af4 in ?? () from /usr/lib/vfp/libpango-1.0.so.0
#8  0x40977d48 in pango_layout_get_unknown_glyphs_count () from /usr/lib/vfp/libpango-1.0.so.0
#9  0x4037a200 in ?? () from /usr/lib/vfp/libgtk-x11-2.0.so.0
#10 0x40381f94 in ?? () from /usr/lib/vfp/libgtk-x11-2.0.so.0
#11 0x40a80c04 in g_type_create_instance () from /usr/lib/libgobject-2.0.so.0
#12 0x40a62518 in ?? () from /usr/lib/libgobject-2.0.so.0
#13 0x40a62fc8 in g_object_newv () from /usr/lib/libgobject-2.0.so.0
#14 0x40a63aec in g_object_new_valist () from /usr/lib/libgobject-2.0.so.0
#15 0x40a63c5c in g_object_new () from /usr/lib/libgobject-2.0.so.0
#16 0x42b65cf8 in nsLookAndFeel::GetMetric (this=<value optimized out>, 
    aID=nsILookAndFeel::eMetric_SelectTextfieldsOnKeyFocus, aMetric=@0xbea3ecd0)
    at nsLookAndFeel.cpp:379
#17 0x43aab644 in nsEventStateManager::Init (this=<value optimized out>)
    at nsEventStateManager.cpp:323
#18 0x4384d200 in nsPresContext::Init (this=0x3421b8, aDeviceContext=<value optimized out>)
    at nsPresContext.cpp:722
#19 0x4383928c in DocumentViewerImpl::InitInternal (this=0x341d10, aParentWidget=0x251950, 
    aState=<value optimized out>, aDeviceContext=0x341f30, aBounds=@0xbea3ef44, 
    aDoCreation=1, aInPrintPreview=0) at nsDocumentViewer.cpp:805
#20 0x43839bcc in DocumentViewerImpl::Init (this=0x0, aParentWidget=0x0, 
    aDeviceContext=0x43839bcc, aBounds=<value optimized out>) at nsDocumentViewer.cpp:637
#21 0x424600d8 in nsDocShell::SetupNewViewer (this=0x260a38, aNewViewer=<value optimized out>)
    at nsDocShell.cpp:6155
#22 0x42458fc4 in nsDocShell::Embed (this=0x260a38, aContentViewer=0x341d10, 
    aCommand=<value optimized out>, aExtraInfo=<value optimized out>) at nsDocShell.cpp:4660
#23 0x42462760 in nsDocShell::CreateAboutBlankContentViewer (this=0x260a38)
    at nsDocShell.cpp:5065
#24 0x424630dc in nsDocShell::EnsureContentViewer (this=0x260a38) at nsDocShell.cpp:4944
#25 0x4246b744 in nsDocShell::GetInterface (this=0x260a38, aIID=@0x43cfd7bc, aSink=0xbea3f178)
    at nsDocShell.cpp:428
#26 0x401455b4 in nsGetInterface::operator() (this=0xbea3f194, aIID=@0x43cfd7bc, 
    aInstancePtr=0xbea3f178) at nsIInterfaceRequestorUtils.cpp:53
#27 0x4399732c in nsCOMPtr<nsIDOMDocument>::assign_from_helper (this=0xbea3f1a0, 
    helper=<value optimized out>, aIID=<value optimized out>)
    at ../../../dist/include/xpcom/nsCOMPtr.h:1292
#28 0x439981c4 in nsCOMPtr (this=0xbea3f1a0, helper=@0xbea3f194)
    at ../../../dist/include/xpcom/nsCOMPtr.h:694
#29 0x43ba2c24 in nsGlobalWindow::GetDocument (this=<value optimized out>, 
    aDocument=0xbea3f1c4) at nsGlobalWindow.cpp:1970
#30 0x42d06ac4 in nsWindowWatcher::URIfromURL (aURL=0x33ade0 "chrome://messenger/content/", 
    aParent=<value optimized out>, aURI=0xbea3f508) at nsWindowWatcher.cpp:1329
#31 0x42d072a4 in nsWindowWatcher::OpenWindowJSInternal (this=<value optimized out>, 
    aParent=0x0, aUrl=0x33ade0 "chrome://messenger/content/", aName=0x33ae18 "_blank", 
    aFeatures=0x33b368 "chrome,dialog=no,all", aDialog=1, argc=1, argv=0x33e9a4, 
    aCalledFromJS=0, _retval=0x33e9a4) at nsWindowWatcher.cpp:577
#32 0x42d08914 in nsWindowWatcher::OpenWindow (this=0x15a000, aParent=0x0, 
    aUrl=0x33ade0 "chrome://messenger/content/", aName=0x33ae18 "_blank", 
    aFeatures=0x33b368 "chrome,dialog=no,all", aArguments=0x401ca2f4, _retval=0xbea3f720)
    at nsWindowWatcher.cpp:478
#33 0x401ca2f4 in XPTC_InvokeByIndex (that=<value optimized out>, methodIndex=0, 
    paramCount=215672, params=0x1) at xptcinvoke_arm.cpp:217
#34 0xbea3f774 in ?? ()