An interesting question; well asked!
The answer is "no", in both directions.
Here is a DTD which has no equivalent in XSD:
<!ELEMENT e (#PCDATA | e)* >
<!ENTITY egbdf "Every good boy deserves favor.">
The set of character sequences accepted by this DTD includes both <e/> and <e>&egbdf;</e>, but not <e>&beadgcf;</e>.
Since XSD validation operates on an information set in which entities have all already been expanded, no XSD schema can distinguish the third case from the second.
A second area where DTDs can express constraints not expressible in XSD involves NOTATION types. I won't give an example; the details are too complicated for me to remember them correctly without looking them up, and not interesting enough to make me want to do so.
A third area: DTDs treat namespace attributes (aka namespace declarations) and general attributes in the same way; a DTD can therefore constrain the appearance of namespace declarations in documents. An XSD schema cannot. The same applies to attributes in the xsi namespace.
If we ignore all of those issues, and formulate the question with respect only to character sequences containing no references to named entities other than the pre-defined entities lt, gt, etc., then the answer changes: for every DTD not involving NOTATION declarations, there is an XSD schema that accepts precisely the same set of documents after entity expansion and with 'same' defined in a way that ignores namespace attributes and attributes in the xsi namespace.
In the other direction, the areas of difference include these:
XSD is namespace aware: the following XSD schema accepts any instance of element e in the specified target namespace, regardless of what prefix is bound to that namespace in the document instance.
<xs:schema xmlns:xs="..." targetNamespace="http://example.com/nss/24397">
<xs:element name="e" type="xs:string"/>
</xs:schema>
No DTD can successfully accept all and only the e elements in the given namespace.
XSD has a richer set of datatypes and can use datatypes to constrain elements as well as attributes. The following XSD schema has no equivalent DTD:
<xs:schema xmlns:xs="...">
<xs:element name="e" type="xs:integer"/>
</xs:schema>
This schema accepts the document <e>42</e> but not the document <e>42d Street</e>. No DTD can make that distinction, because DTDs have no mechanism for constraining #PCDATA content. The closest DTD would be <!ELEMENT e (#PCDATA)>, which accepts both sample documents.
XSD's xsi:type attribute allows in-document modifications of content models. The XSD schema described by the following schema document has no equivalent DTD:
<xs:schema xmlns:xs="...">
<xs:complexType name="e">
<xs:sequence>
<xs:element ref="e" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="e2">
<xs:sequence>
<xs:element ref="e" minOccurs="2" maxOccurs="2"/>
</xs:sequence>
</xs:complexType>
<xs:element name="e" type="e"/>
</xs:schema>
This schema accepts the document <e xmlns:xsi="..." xsi:type="e2"><e/><e/></e> and rejects the document <e xmlns:xsi="..." xsi:type="e2"><e/><e/><e/></e>. DTDs have no mechanism for making content models depend on an attribute value given in the document instance.
XSD wildcards allow the inclusion of arbitrary well-formed XML among the children of specified elements; the closest one can come to that with a DTD is to use an element declaration of the form <!ELEMENT e ANY>, which is not the same because it requires declarations for all the elements which in fact appear.
XSD 1.1 provides assertions and conditional type assignment, which have no analogues in DTDs.
There are probably other ways in which the expressive power of XSD exceeds that of DTDs, but I think the point has been illustrated adequately.
I think a fair summary would be: XSD can express everything DTDs can express, with the exception of entity declarations and special cases like namespace declarations and xsi:* attributes, because XSD was designed to be able to do so. So the loss of information when translating a DTD to an XSD schema document is relatively modest, well understood, and mostly involves things most vocabulary designers regard as DTD artefacts not of substantive interest.
XSD can express more than DTDs can, again because XSD was designed to do so. In the general case, translation from XSD to DTD necessarily involves loss of information (the set of documents accepted may need to be larger, or smaller, or to be an overlapping set). Different choices can be made about how to manage the loss of information, which gives the question "How does one best translate an XSD into DTD form?" a certain theoretical interest. (Very few people, however, seem to find it an interesting question in practice.)
All of this focuses, as did your question, on documents as character sequences, on languages as document sets, and on schema languages as generators of languages in that sense. Issues of maintainability and information present in the schema that does not turn into differences in the extension of document sets (e.g. the treatment of class hierarchies in the document model) is left out of account.
