I know this isn't the answer you want, but the real answer is "it depends." It depends on things like how many indices and shards you need to index/query, how much data you plan to push in per-day/week/month, and what your query profiles look like.
First of all, good job in considering dedicated master-eligible nodes. You're a step ahead of things! Master-eligible nodes tend to be memory sensitive (you really don't want them to run out of heap!) but at the same time, you don't want to set the heap too large, as it can lead to long garbage collection, which can cause real cluster problems. If you plan to have a very large number of shards, a very large number of indices, very large mappings, or other things in the cluster state you'll need more heap on master-eligible nodes. Still, we usually don't see most master-eligible nodes need a huge heap. They don't store a lot on disk.
Data nodes are writing and reading data, so things like SSDs tend to help with throughput on both sides if you need it. They also process aggregations, so heap can be important.
As to dedicated client nodes, we don't often see people actually need them. Sometimes, but not always -- especially on small setups. You may want to consider not including them to start and only add them if/when you get to that point.
But the best advice I can probably give is to watch the video at https://www.elastic.co/elasticon/conf/2016/sf/quantitative-cluster-sizing . This will give you a good framework for how to size and architect your clusters.
