Windows accepts DLL overrides if they reside in the same folder as the program attempting to use them. In other words, if there's a Wine d3dx9_43.dll in the same folder as th13.exe, it'll try to use Wine's dll instead of the system one that's protected from replacement. That way you can swap them out at will, and it only affects th13.exe.
Which also leads me to the conclusion. After compiling Wine from git under MSys/MinGW (which took nearly 4 hours, and ultimately failed while building d3d10.dll), plus manually going in and making some of the other DLLs because the game was still crashing, I tested it again with all the successful* freshly-compiled Wine DLLs in th13's directory.
*d3d8.dll, d3d9.dll, d3dx9_43.dll, d3d10core.dll, ddraw.dll, dxgi.dll, libwine.dll, and wined3d.dll
No crash, and actual gameplay started. At first, I was getting the same performance issue I was under Ubuntu. I tried shuffling some of the DLLs away for reasons of cleanliness - if I don't need an overridden DLL, don't have it in there. ddraw.dll seems to have been the performance culprit. Turns out, the only DLL actually necessary to override is d3dx9_43.dll, the same one that was crashing using the normal DirectX and prompted this thread in the first place.
So what it simply looks like is something's up with the MS version of that file, at least on my hardware. Wine's version works perfectly, and I'm getting a full ~60fps, just like the previous games.
Thanks for all the help. It spurred me to actually test this idea.