After rereading your first post I now see that you really want the order to match the order established by your where clause, which has nothing to do with the way the data was created or any field in the data. (All of the terms you used to describe your problem are associated with user data entry directly to the database itself, not just user interaction through the query, so your original post was open to confusion).
To do that you would have to parse the where clause to get the list of unique values and then create a two dimensional array or some other collection object to preserve that order and store the cursor records to match that order. Cursors cannot be ordered by anything other than a field (even unsorder data is actually ordered by the ObjectID/FID).
Parsing would be easier if you build a where clause with the IN operator:
"APT IN (''DFW', 'STL', 'ORD')"
Your Like expression is not any different from the above since it had no wildcards in it. If it had used wildcards then you would have to parse the original format of your where clause and insert to the the array/collection based on comparisons that matched the wildcard format order.
In any case, no cursor can do what you want without parsing the original where clause into three separate where clauses that you run separately in the order that you parsed them. You would have to store and output the result through some form of intermediate list/array/collection that combines them in that specific order. You cannot return a single table view or directly bound datagrid of the full selection that will match the user input order.
What you want would operate in a way that is the exact opposite of cursor optimization, so thank God no database designer ever considered making SQL work that way. All forms of ordering data cause cursor performance to suffer to one degree or another, so by default none is done, and only sort orders by field are permitted since those can be optimized by indexes.
