No, it's not an anti-pattern. I can think of a number of practical use cases for this:

1. If you want to use compile time checking to make sure collections of objects only conform to one particular subclass. For example, if you have MySQLDao and SqliteDao in your system, but for some reason you want to make sure a collection only contains data from one source, if you use subclasses as you describe you can have the compiler verify this particular correctness. On the other hand, if you store the data source as a field, this would become a run-time check.
2. My current application has a one to one relationship between AlgorithmConfiguration + ProductClass and AlgorithmInstance. In other words, if you configure FooAlgorithm for ProductClass in the properties file, you can only get one FooAlgorithm for that product class. The only way to get two FooAlgorithms for a given ProductClass is to create a subclass FooBarAlgorithm. This is okay, because it makes the properties file easy to use (there is no need for syntax for many different configurations in one section in the properties file), and it's very rare there will be more than one instance for a given product class.
3. @Telastyn's answer gives another good example.

Bottom line: There isn't really any harm in doing this. An Anti-pattern is defined to be:

An anti-pattern (or antipattern) is a common response to a recurring problem that is usually ineffective and risks being highly counterproductive.

There is no risk of being highly counterproductive here, so it's not an anti-pattern.

No, it's not an anti-pattern. I can think of a number of practical use cases for this:

1. If you want to use compile time checking to make sure collections of objects only conform to one particular subclass. For example, if you have MySQLDao and SqliteDao in your system, but for some reason you want to make sure a collection only contains data from one source, if you use subclasses as you describe you can have the compiler verify this particular correctness. On the other hand, if you store the data source as a field, this would become a run-time check.
2. My current application has a one to one relationship between AlgorithmConfiguration + ProductClass and AlgorithmInstance. In other words, if you configure FooAlgorithm for ProductClass in the properties file, you can only get one FooAlgorithm for that product class. The only way to get two FooAlgorithms for a given ProductClass is to create a subclass FooBarAlgorithm. This is okay, because it makes the properties file easy to use (there is no need for syntax for many different configurations in one section in the properties file), and it's very rare there will be more than one instance for a given product class.
3. @Telastyn's answer gives another good example.

Bottom line: There isn't really any harm in doing this. An Anti-pattern is defined to be:

An anti-pattern (or antipattern) is a common response to a recurring problem that is usually ineffective and risks being highly counterproductive.

There is no risk of being highly counterproductive here, so it's not an anti-pattern.