In general, HDLs come in two flavors -- structural and behavioral. In a behavioral HDL program you have things like if..else statements and variables. What happens is that the synthesis tool (basically the "compiler" for HDLs) has to figure out how to design a logic circuit that has the described behavior. This is not trivial and most HDLs that support behavioral modeling need the code being synthesized to stay very close to a set of design patterns that it can deal with -- anything outside of that and things go off the rails really quick.
The other flavor is structural and that is what the Nand2Tetris HDL is. With a structural program, all you are doing is describing how various parts are hooked together -- it is a direct analog to an electrical schematic. So you need to come up with a logic circuit that does what you want and then describe that circuit using HDL statements.
For your task, seeing if In is between X and Y, you need to first decide whether the limits are inclusive or exclusive. If X and Y are unknown (if they are inputs to the circuit as well), then you want a numerical comparator circuit. You would use two of them and then your output logic just uses those two values to determine the final output.
If your limits are fixed and sufficiently "nice", sometimes you can greatly simplify things. Look at the binary patterns for the numbers you are working with:
16384 => 0100 0000 0000 0000
24575 => 0101 1111 1111 1111
If your limits are inclusive, then every number within the range of interest must start with 010 and the rest of the bits don't matter. So your logic circuit would look something like:
Nor(In[13], In[15], v1);
And(In[14], v1, out);
N2T doesn't have you make a Nor gate, but you could do so if you wanted. Or you could expand it out using parts that you do have:
Not(In[13], in13_b);
Not(In[15], in15_b);
And(in13_b, in15_b, v1);
And(In[14], v1, out);
Why do you want to do this? If you are trying to do it as part of the standard Nand-2-Tetris project, then you are probably going off down a rabbit hole. If you are doing something above and beyond, like adding a hardware capability to check if you are addressing screen memory, then that might be useful, however you are already decoding the address lines to determine if the screen is being accessed, so just piggy back on that logic.