The reason that those properties don't serialize themselves (write themselves to the .designer.* file) is that all of the properties have corresponding ShouldSerialize[PropertyName]() methods that tell the designer not to serialize them if the BrowseDialog is inherited (meaning it's a subclass like the one you've created). The reason for this logic is as follows:
The BrowseDialog is designed to be inheritable so that you can, say, create a CustomersBrowseDialog and reuse it througout your application. So, you create a class, inherit from BrowseDialog and through the component designer, set all of the properties on the custom BrowseDialog so that you only have to set them once. However, whenever you drop the custom browse onto a form, all of those properties are re-serialized. Meaning that all of the collections (SearchFields, ResultsLayout, etc.) get doubled-up. It also means that if you go to the component designer and change a property, it is not propagated throughout your app to all of the instances of that custom browse (because the properties were serialized at whatever value they where when the custom browse was dropped on the form). So, we fixed the BrowseDialog so that it will not serialize any of the property values of an inherited dialog. This allows all of the properties within the component designer to be serialized, but when you drop it on a form, none of them are re-serialized (just the BusinessObjectToPopulate, since it it specific to the instance of the BrowseDialog).
So, if you don't want this functionality, you can override the IsInheritedBrowseDialog() method of the business object. When it returns true, the properties will not be serialized. The base code checks to see if the current objects type is a subclass of BrowseDialog. But, you generally want to leave the functionality and set the properties for the custom browse within the component designer of your custom browse so you don't have to set them on every instance of the browse dialog that you drop on a form.