Actually, no. Creating and destroying windows is highly discouraged in DllEntryPoint(), see: Dynamic-Link Library Best Practices:
Guess where the CreateWindow/Ex() and DestroyWindow() functions reside - in user32.dll !
0x0EEDFADE is the exception code when a Delphi exception escapes into the C++ runtime. So, what exception type exactly is the TForm destructor actually throwing? My guess is EOSError if DestroyWindow() fails. But a TForm destruction does a lot of things, so there could be any number of reasons why it would fail while the DLL is in the process of being unloaded from memory.
Perhaps, if your DLL's TApplication object were already destroyed (or in the process of being destroyed). You should run your code in the debugger and verify that. Your global Form1 variable would not be updated in that situation, so you would have a dangling pointer. One way to handle that would be to assign NULL to your variable in your Form's destructor.
But really, this is not the kind of stuff that you should be doing in your DllEntryPoint() to begin with. It would be better to export a couple of functions from your DLL that the loading app can then call after loading the DLL and before unloading it.