Performance Monitoring for Prepared SQL?
You would most likely need to trap statement-level events since the "completed" RPC call for sp_execute isn't going to show the batch itself.

Also, you need more than just the SPID. Session IDs get re-used, hence it is not granular enough of a key. You will also need the Connection ID since that is more unique and is what the cached array of prepared statements is tied to.

Finally, what is the impetus for moving to prepared statements? The only benefit of them is saving some number of bytes in the network request if your app is frequently sending over the same parameterized queries. It is generally better to call Stored Procedures so that you are not sending over the queries each time anyway. I did recently here someone suggest that prepared statements could be faster than Stored Procedures, but it was a very specific use-case: simple DML statements executed at least 1 - 2 BILLION times per day (i.e. the same INSERT INTO dbo.Table (@1, @2, @3); executed 2 billion times with different values).

If you are executing non-parameterized ad hoc queries, then using prepared statements is worthless at best, and at worst it is a step backwards given how much harder they are to monitor.

Please also see my answer, also here on DBA.SE, to the following question:

What is the sense and benefit of using SqlCommand.Prepare()?