The designer approach is always an option, but I wrote the code below in another post, it could be of some use to you:
// create the group by clause & result set fields
ResultsetFields fields = CustomResultsetFields.AuthorContentList();
IGroupByCollection groupByClause = new GroupByCollection();
for (int i = 0; i < fields.Count ; i++)
{
IEntityField2 field = fields[i] as IEntityField2;
if (field.AggregateFunctionToApply == AggregateFunction.None)
{
groupByClause.Add(field);
}
}
What the code really does is loop through an entity and adds the field object to the IGroupByClause.
AuthorContentList is a method that returns a ResultsetFields object. I dont see why you couldnt take a similar approach, as you should be able to add all fields in entity 1,2,3,... n to a ResultsetFields collection.
You could also probably get really crazy and use the microsoft configuration application block to store an array of entities to use for a given typed list. When your framework initializes or gets called it could check the xml file and build the field list for you based on the contents of the xml file. This would stop you from needing to re-compile for each "custom typed list" that you needed to create. The tradeoff would be that xml serialization isnt that fast, but once the object graph is loaded, its loaded.