But how do you practice these and get feedback on whether or not what you say/do is good?
I assume that gaining the substantive knowledge isn't the issue--it sounds more like you want to know how to put it all together, structure your responses, understand the criteria, etc.
I think there are a couple broad approaches for overall structure
1) Spend a lot of time up front gathering requirements; largely functional requirements, but also a major point with a lot of the better questions (i.e. questions more like "design a parking lot" than "design Twitter") is often to get there is a performance trade-off (e.g. maybe for certain things, consistency is more important than latency/speed considerations).
2) You can either do your main diagram or do data model first.
3) After high-level diagram and data model, discuss single-points of failure, additional scaling issues, etc.
The overall vibe of communication here is that you want to be discussing trade-offs and various tech choices. The most obvious, and something which will come up almost all the time, is SQL v NoSQL databases. It's mostly pretty straight-forward to list trade-offs for a given use-case/scenario and make a case for one over the other.
There often won't be right answers to various components of the exercise. Again, NoSQL and SQL is a paradigmatic example. In theory, you can do anything in NoSQL and vice versa, but knowing the trade offs is key.
System design interviews are basically like law school exams. I can't help but note that even though basically nobody reading this will have gone to law school, and thus there is nobody nodding their head right now.