[SalesForce] Database schema export

In short after taking a deeper looker at this for you, I have to conclude the answer to your question is that you can only be partially successful in emulating the filters used by Schema Builder...

The isCustom method will help with the first obviously, the second two are harder to separate. The following uses the fact that Schema Builder seems to favour objects with Record Types (via getRecordTypeInfos). So I based further filtering on this. Note that this is governed method so some filtering on isCreateable objects was also needed. Thus some accessible (but not createable objects) are eliminated sadly.

Anyway, since I spent some time on this for you, I thought I would share anyway. Hopefully this gives you some thoughts and if nothing else a conclusion you can move forward with some other approach or variation on this on. Enjoy!

Following is the best I think you will achieve to cover Custom vs Standard.

Map<String, Schema.SObjectType> gd = Schema.getGlobalDescribe(); 
Set<String> standardObjects = new Set<String>();
Set<String> customObjects = new Set<String>();
for(Schema.SObjectType d : gd.values())
{
    Schema.DescribeSObjectResult ds = d.getDescribe();
    if(!ds.isCreateable())
      continue;
    if(ds.isCustom() == false && ds.getRecordTypeInfos().size() > 0)
        standardObjects.add(ds.getName());
    else if(ds.isCustom())
        customObjects.add(ds.getName());
}
List<String> sortedNames = new List<String>(customObjects);
sortedNames.sort();
for(String name : sortedNames)
  System.debug('Custom object: ' + name);
sortedNames = new List<String>(standardObjects);
sortedNames.sort();
for(String name : sortedNames)
  System.debug('Standard object: ' + name);

This results in the following, which gets pretty close, but no cigar....

01:53:17.135 (135755000)|USER_DEBUG|[21]|DEBUG|Standard object: Account

01:53:17.135 (135835000)|USER_DEBUG|[21]|DEBUG|Standard object: Campaign

01:53:17.135 (135903000)|USER_DEBUG|[21]|DEBUG|Standard object: CampaignMember

01:53:17.135 (135972000)|USER_DEBUG|[21]|DEBUG|Standard object: Case

01:53:17.136 (136045000)|USER_DEBUG|[21]|DEBUG|Standard object: Contact

01:53:17.136 (136117000)|USER_DEBUG|[21]|DEBUG|Standard object: ContentVersion

01:53:17.136 (136188000)|USER_DEBUG|[21]|DEBUG|Standard object: Contract

01:53:17.136 (136259000)|USER_DEBUG|[21]|DEBUG|Standard object: Event

01:53:17.136 (136326000)|USER_DEBUG|[21]|DEBUG|Standard object: Idea

01:53:17.136 (136393000)|USER_DEBUG|[21]|DEBUG|Standard object: Lead

01:53:17.136 (136465000)|USER_DEBUG|[21]|DEBUG|Standard object: Opportunity

01:53:17.136 (136534000)|USER_DEBUG|[21]|DEBUG|Standard object: Product2

01:53:17.136 (136601000)|USER_DEBUG|[21]|DEBUG|Standard object: Solution

01:53:17.136 (136668000)|USER_DEBUG|[21]|DEBUG|Standard object: Task

It's the parent "SObject" type that represents Task and Event. It appears only in relationship queries, such as:

SELECT Id, (SELECT Id, Subject, ActivityDate FROM ActivityHistories) 
FROM Account

Of course, this is only a convenience object, because it really represents two distinct objects, and only serves a purpose in queries to collapse both tasks and events into ActivityHistories or OpenActivities.