In short, no.
Or rather, yes, but you don't want to do that.
Note, by the way, that "can we do that" and "is it 100% secure" in your question are different, antipodal things. Much like "MT" and "secure" are antipodal. All generated pseudorandom numbers (including those coming from secure pseudorandom generators and those coming out of cryptographic hash functions are deterministic, so they cannot be 100% secure anyway). Now, MT, which you gave as an example, is not in any way secure, it is very easily exploited. If you meant "secure" in a way of "are we confident that the bits will look random", then that's a different question. But in that case, you most likely want to use a generator that is orders of magnitude faster than a cryptographic hash.
A cryptographic hash function can be used to generate (pseudo-) random bits of an apparent quality comparable to dedicated random number generators. I say "apparent" because although cryptographic hash functions are designed with some things in mind that are desirable features of random number generators as well (think e.g. avalanche), they are not designed to be random number generators.
So, they kinda work as such, mostly, but it's not their real purpose and you do not have a hard guarantee that they will pass all tests that a specifically designed high-quality random number generator will pass (MT doesn't even pass them all either, by the way, it's comparatively poor).
The fact that you can use a cryptographic hash as a random generator is demonstrated by the fact that for example, the secure random number generator in at least one free open source operating system is implemented in exactly this way.
Then why am I saying "no"?
A hash function (cryptographic or not) can be considered being a sort of entropy extractor.
N bits and the function somehow produces
M bits from these (and usually
N >> M) in an obscure, hard to predict way such that you cannot easily find collisions, etc etc.
M bits that the function outputs are (pseudo) random, or at least as good as. So you could say that the function extracts
M bits of entropy from the message.
That is the exact reason why, for example, DJB recommended that you use a hash function after you did a curve25519 exchange and want to use the result as encryption key for your block cipher. You have some curve point which is not totally random, and it has more bits than you actually need, but also you know that it only has slightly fewer than 128 bits of entropy somewhere inside, and you do not know where. Obviously you want to use all the entropy that you're given. What to do?! Which bits should you use?
Hashing the point extracts that entropy, and ensures you don't throw any of it away.
So, let's think about what happens in our random number generator. We seed it with a certain amount of entropy, and then we keep extracting entropy from it forever. Wait a moment, if we extract some, what about remaining entropy? Yep, you guessed right. Eventually, very soon, we run out of entropy. It's still a random-looking deterministic sequence, of course. However, it is a sequence about which we practically do not know anything (e.g. what is its period lenght?).
Doesn't any random number generator have the entropy problem? Well yes, output is deterministic, and there is a finite number of numbers in an integer, so necessarily, sooner or later, you get the same sequence of numbers again, but this is a known problem and it's something that is explicitly addressed in the design (not so in the design of a cryptographic hash!).
Good generators try to maximise the period length (and some other things).
That's why MT has such a ridiculously large state. This huge state exists only to turn a rather poor generator into one with a very long period with a very large k-distribution (by only ever updating a small part of a huge state independently, and iterating over it).
PCG or xoroshiro variants (which, too, are not cryptographically secure) achieve practical periods (and, except for k-distribution, better properties otherwise!) with much, much smaller state. I say "practical" because one needs to realize that there is absolutely no difference between a 2^256 and a 2^19937 period. Even in massively parallel applications, a 2^256 period which can be subdivided with skip-ahead into 2^128 independent, non-overlapping sequences, is way more than you can use in your lifetime, even with an utopian farm of impossibly fast supercomputers. So, that's "infinite" for all practical purposes, just like 2^19937 is only "infinite", too.
In the case of the previously mentionend secure random generator used in an operating system, running out of entropy isn't very much a problem because it is being re-seeded all the time. So it never (well, never is a lie... let's say rarely, in normal conditions) runs out of entropy.