It sounds like you do not have the time to implement a customization; therefore, take a look at the facility called Inspection View. Keep in mind that it seems your requirement probably needs a customization to provide the level of detail your consumers appear to be asking for in a more organized or concise way.
Inspection View - DevTest Solutions - 10.0 - CA Technologies Documentation <-- this link speaks to the inspection view.
Some screen shots from a live service look like these:
Accessing by right click on a service, then selecting Inspection View.
Locate the operation and view various request-side artifacts including the actual inbound request:
Navigate to the response side. Note ID below ties to the response located in the VSI:
When a high number of service calls are being made, the above process can be confusing for the average service consumer (channels) because their requests are commingled along with every other consumer's requests. Paging through a significant amount of history to find their respective request/responses may be problematic.
Other Manual Approaches:
The information above is also written into the vse.log, vse_matches.log, and VS_yourService.log (where yourService is the name of your virtual service) if the logging.properties file is set to INFO. The data found in the logs requires some stitching based on the timestamp and other inputs to align the request and response information. DevTest does not provide an OOTB tool that stitches the log output into a readable format. This activity is most likely something your consumers will not be able to do with ease. Similarly, the logs contain more information than just the request / response information.
Custom Approaches:
Some customers have implemented custom logging routines in their models to write additional supporting information into the DevTest log files or separate the output into service-specific log files. These approaches are custom in that the VSM must be modified to write the request/response output to the file system. This approach is not overly complex, but you indicated that you a) need a mechanism to turn it on & off, and b) you indicated that you have a high number of services so modifications to each service may be a limiting factor.
Additionally, customers that use tools such as Splunk often insert custom logging messages into the DevTest logs so that Splunk can consume the information and make it query-able. I had a very large customer use this technique for all virtual services. Each step in the model logged information (prefixed with an identifying key) that enabled the customer to use Splunk queries to retrieve not only the request / response, but much more information about the flow the service executed.