Whilst not impossible to achieve with some level of bespoke coding, Viv, you're still showing some confusion over the events and how they are triggered. The events are used by designers to provide a programmed response to users opening forms, closing them, updating fields and so on. They are not intended to fire when designers are modifying the underlying design, as this is just a very small part of the lifecycle of a form or report.
I would say at this stage that the effort you could expend for what is likely to be a very small gain in overall productivity is far outweighed by the time it would take for what is in effect a one-off application.
I find that designing an Access report is a time-intensive process - regardless of what the built-in wizards can do to start you off. Resizing fields, aligning them, and doing all the other bits and pieces that make the report readable to an end user takes a lot of effort.
In general, there is simply no easy way that a form can be used as the basis for an automated translation to a workable report. I can't say that what you want to achieve is impossible; what I can say for sure is that if you decide to design a new wizard to do it for you the time you will spend perfecting it will far outweigh the time it would have taken you to do it manually.
The cost-benefit question you have to ask is 'am I likely to need this tool so often that I can afford to spend several months learning how to set it up and then perfecting it?'. If you can answer Yes then go ahead; if not, and my advice would definitely be NOT, continue doing it manually!
-Stewart