I don't think that you can solve it directly. The inserted view only exists within the trigger itself, so you can't interrogate it via dynamic SQL (because it executes in a different context than the trigger does).
You could probably create the temp table outside of the trigger, then populate it using static SQL from inside the trigger.
It boils down to a question of what exists when. If you can create a permanent table, or a temp table that exists before the trigger fires you should be Ok. You may be able to make a global temp table work if you create it with dynamic SQL and populate it with static SQL, but I wouldn't even bet on that because the timing would be so sensitive.
I don't know of any way to access the statement that launched an instead of trigger. I don't think there is any syntactical way to "fall back" to the invoiking statement. While an extended stored procedure could access the token stream in the buffer and might be able to reconstruct the invoking statement, there isn't any way to invoke it dynamically because the INSTEAD OF trigger would still be running so it couldn't be dropped in order to allow the invoking statement without simply re-launching the INSTEAD OF trigger.