FIR filter design and implementation - sample rate and number of taps
I'm unable to visualize the real-valued inverse-DFT FIR filter coefficients you describe in your Step 5. But no matter. My answer for A: When you use a large number of DFT bins to yield fine granularity of your frequency-domain representation of your desired frequency response, the greater will be the number of nonzero coefficients remaining after you window the output of your inverse DFT. And the larger the number of nonzero coefficients, the greater will be the number of filter computations needed per filter input sample. Only you can decide how many multiplications and additions you're willing to perform per filter input sample. By the way, I'm wondering how many nonzero coefficients you're contemplating at this time.

My answer for B: I'm not sure what the asterisk symbol means in your y(n) = SUM_over_m[h(m)*x(n-m)] expression. In any case, you typically implement your FIR filter by convolving your filter's input sequence with your filter's nonzero coefficients. If your have 100 nonzero coefficients then you must perform 100 multiplies and 99 additions per filter input sample. (Depending on your computing hardware, there may be a way to reduce the number of multiplies per input sample to 50. Ask me how.) Now if you have many hundreds of nonzero coefficients then in that case, yes, you'll use what's called the "fast convolution" filtering method which involves both forward- and inverse-DFTs. But CA Charlie, all of this discussion depends on whether your filtering is "real-time" of "offline." As for the 48 kHz data rate, it affects two things: (1) it means your input signal's spectrum can contain no spectral components greater than 48/2 = 24 kHz; and (2) in a real-time implementation you must perform all your "per sample" filtering computations in less than 1/48,000th of a second. (Sorry CA Charlie, I don't understand the question in your final paragraph.)