This won't be that helpful, but underneath most Set implementations is normally a hash table or hash map, where the keys of the table represent the set, since they are unique.
Great, so how does a hash table work? The keys need to support a hash method that tries to differentiate instances of a class by turning all identifying properties into a single integer.
Fantastic, what does this have to do with storing unique elements? The hash table implementation will get the hash of an object, then do a calculation (smear) to decide what index in an array should be used for an object with that hash. Two objects may hash to the same value, so if there is a collision a test is done to see if the objects are equal if there's already an object at the index determined. If equal, then the value (the table maps keys to values) is updated in the same position in the value array. If the key at this index is not equal, this constitutes a collision, and a new index must be determined (sometimes the very next index, sometimes a resmear). The same process is used if that position is occupied.
What this boils down to is that a Set's elements are stored in an array (that may be sparse, having unused elements), and which index is used for each element is determined by its hash code and the smearing algorithm.
While things like "any element" seem a bit magical, this could be as simple as the first element in the array to an actual random position. Contains object will do a key lookup like the object is being stored as described above, but when the index is found (through repeated smearing if needed), ultimately YES or NO is returned based on the key being present in the table. Filtering would just be enumerating the Set and testing each element. Enumerating can be as simple as walking through the array finding non-nil elements.
This isn't enough info to implement a hash-based set yourself, but hopefully it's a good enough sketch that you can imagine the mechanics.
-Lee