How interesting! I sincerely wish you get enough takers to get the tool adapted for ProcessBook.
Another option - depending on the type of project you have, obviously - could be to port your code to a .NET Add-In for ProcessBook. Then I'm sure there would be a wider selection of tools and profilers you could choose from, for .NET.
Also, maybe we could help you sorting out some particulars of your code? Is there anything you are having problems with, that you'd like to bring up here?
I had a similar thought as Steve's, but I was thinking using classic Visual Basic 6. VBA and VB6 are essentially the same language, so porting would be much easier. I suspect the performance of the language itself would be more similar than VBA to .NET - so if you still planned on keep the code in VBA (but just profile it in something else) you may get better results. Many profiling tools still support VB6.
Using an add-in would match VBA perfromance better than using a standalone executable (not that anyone has suggested doing this). There will be some differences in using ProcessBook's automation interface from within the application itself (add-ins, VBA) and between 2 seperate applications.
All of this assumes you have access to these development tools.
You could write your own timer functions and inject them directly into your VBA code. Something like:
... existing code...