No. It won't work, at least not reliably. I'm surprised it did anything with AtariWorks.
Traditionally, to do the sort of thing you're talking about, one has a separate desk accessory that does the UI stuff. However, that happens *before* the driver is loaded, to alter a configuration in the driver. In the scenario you describe, a desk accessory wouldn't work because it would normally be inside evnt_multi when the print operation is being done, and since the application printing isn't calling any event library functions at the moment, there's no way to kick the accessory into action. (This might work differently under MultiTOS.)
There are several issues. First, there's no associated application registered with AES. Second, while device drivers are standard program files, they don't contain the same startup code that a regular program would have. They normally don't configure a stack. They don't shrink the TPA.
My guess regarding your crash is stack overflow, BTW. If all you're doing is using the file selector, then *maybe* you can get it working by configuring a decent-sized stack to use while making the fsel_input call. Also, if you're going to set up a stack, consider switching to user mode as well, then switching back afterwards. I don't recall details, but I have a vague memory that there is some potential issue involved with calling AES from supervisor mode.
I'm presuming you're wanting to select a target PDF filename. Your best bet is probably to generate filenames that include a timestamp, like "20160117az.pdf" where the last two letters represent the hour and minute in some fashion.