It would seem to be natural that you would often want to display in the results a superset of the fields that the user may search on. But of course, showing 'CustomerID' in the results is less meaningful than showing 'CustomerBO.Name'.
This is particularly true when the user is browing results based on search criteria other than the one in question. For example, searching for customers who ordered a particular item might bring up fifty different records. Clearly the name of the customer is better in this scenario than a lone ID to let the user know whether he should refine his search.
An alternative to direct support a la SearchFields would be to allow the BusinessObjectType to be of Type V while the BusinessObjectToPopulate could be of Type D. And then provide a mapping from properties of V to properties of D, or more simply, require that the set of properties of V be a subset of the set of properties of D. In other words, populate the BusinessObjectToPopulate with the fields required by its type, assuming the same properties will always exist on the BusinessObjectType (Type V).
The developer then could simply define a view of the desired type where all the lookup values are expanded. I typically have at least one such view on any interesting type anyway to make reporting easier. So using the earlier example, I would have CustomerID, CustomerName, CustomerSortOrder, CustomerCreationDate, and so on and so forth, all as part of my expanded Orders view that was my everything-under-the-sun view of all potentially interesting data points about Orders.
Whew! Hope that made sense...