We do this and it works nicely... you can build custom LDAP
filters/query to define WHICH AD user  account objects are included in
the profile  import.

With this, you can use additional  criteria (attributes) to per-se "tag"
the accounts  as belonging to a human rather than a "system type account"

In our company, a separate process pulls data from our HR database and
imports it into Active Directory. We use the "employee number" as the
key field for this transactions. When this sync process is executed,
records in AD and HR db with a matching "employee number" are keyed and
then other information  from HR (such as phone#, title, department,
business center, country, location, etc) is imported directly into
Active Directory.

Then when the SharePoint profile database sync job runs, we use LDAP
filters to keep out the system  accounts. For example, only AD user
objects with a "Job Title" and an "employee number" present are synched
to the SharePoint Profile dB. If an employee number is missing from the
AD object, then the sync is not performed.

We pull in our profiles  via four custom profile  imports based on AD.
We have OU's for each of our locations with a Users OU in each of
those four locations. So the search  base text looks somethink like
this:

OU=Users,OU=Location1,DC=ourdomain,DC=net

We had origianlly tried using the LDAP query against AD but didn't
like the results  it returned

Our AD db is built manually without a unique identifier such
as an HR employee number (I know, I know). But if it's just a matter of
designating something in our AD profile  that indicates the account is an
active employee account and not an administrative one, shouldn't we
still be able to do that? Can you tell me more about how you set the
filtering up from within the user  profile import settings in SharePoint?