I think for this kind of application, a generate button would probably be undesirable from a UX perspective, especially if the operation performed is as trivial as you make it sound.
Here's what I hacked together in a few minutes, for what I think you are approximately describing:
http://jsfiddle.net/qtY38/4/
(Is jsfiddle still en-vogue?)
The meat being:
function processRecords (form){
var result="";
var inputs = form.elements;
for(var i=0; i<inputs.length; ++i){
var input = inputs[i];
result += input.value;
}
var target = document.getElementById(form.dataset.target);
target.textContent = result;
}
The nice thing about this function is that it assumes nothing about your form other than the fact that it has inputs, and a data-target attribute with the id of the element you want to populate with the result. In addition, it's so cheap to run, that you can do this:
http://jsfiddle.net/CBjPL/1/
The difference being I've removed all submit buttons and added the following snippet:
setInterval(function(){
var forms = document.forms;
for(var i=0; i<forms.length; ++i){
processRecords(forms[i]);
}
}, 100);
Which just automagically actively updates the outputs no matter how the user updates them. This is faster/easier for the user, and as a bonus has a better "wow factor" for the higher-ups.
This may seem kind of wasteful, actively looping and updating text areas that aren't changing, but listening for input changes is kind of a tedious thing in HTML, and this gets the job done easily for moderately sized pages. Especially since all you're doing is walking around the DOM and fiddling with rows. There's probably an optimization to be had in not updating the DOM if you don't have to, but it's not clear to me that that would even be worth it for such a trivial computation. Optimize second!
I'm not sure what you're referring to with respect to "multiple rows per form". If you mean you want to embed multiple collections of inputs/outputs in one element, my gut reaction is... why? As described, you don't really seem to be using the forms as anything other than a trivial wrapper, and it's not like elements introduce a massive overhead.