The problem with this approach is the way that web forms deals with the controls in the page structure. When you create new controls and add them to the page, you must do so reliably on every page cycle. ASP.NET constructs the page control tree from what it finds explicitly defined in the markup and from whatever is added programmatically up to the point the code in question is running. So the controls you put onto a page during one page cycle will not be there automatically on the next cycle unless you explicitly put them there, so the code that looks for the controls won't find anything.
The way this is typically handled is that you put your control generation code in the page load such that it always runs (i.e. no branching for IsPostback). That way, you reconstruct the control structure before event handling takes place. That being said, you may still run into problems with proper restoration of view state which I think is restored prior to page load (it's been a while since I dealt with web forms). This could have adverse effects regarding event firing when control change events are analyzed. This happens because dynamically created controls will have one value when created by code (e.g. a blank text box) but not have their state restored to preserve the value from the last page draw, then a "new" value gets written to the control from the form post action causing an event to fire when it shouldn't.
Working with dynamically generated controls in web forms is very tricky.