I'm using vba as it's much more convenient to work with when you've got a variable like degree of polynomial.
I will have to take your word for it. I'd have to see all the requirements and specifications, and how the f(x) calculation fits into the overall project, but I can see doing this just fine without VBA. I do believe that a programmer should use what he's most comfortable with, and it seems that a lot of people are just more comfortable with symbolic languages like VBA.

a.) want to know about a polynomial of degree n (whatever I choose, there is no largest)
In theory, this is true -- there is no limit to the order of a polynomial. However, I expect there are practical limits. Do you really expect to tackle 50th order polynomials? 100th order? 1000th order? If nothing else, Excel is limited to numbers between -1E308 and 1E308. When you start dealing with 200 to 400th order polynomials, I would expect you to start running into overflow errors.

A couple of questions about converting making_f to a function:

1) Is it necessary to copy each term of the polynomial into the cell below the coefficient? One of the main difficulties I see in converting making_f to a UDF is that you are returning multiple values to the spreadsheet (1 value for each term, and then the overall sum). I find that UDF's are easiest to code if your UDF only needs to return one value to the spreadsheet. So the first suggestion is to identify which values must be returned to the spreadsheet and which of these intermediate values we can simply store inside the procedure (maybe in an array or maybe they don't need to be stored at all).

A function can return multiple values as an array, in which case you can either use the =INDEX() function to determine which value to return, or you can enter the function as an array function and return all the values to a consecutive block of cells.

2) Sub procedures tend not to take arguments -- they extract information directly from the spreadsheet. UDF's, on the other hand, work best if needed information is passed to the UDF through the argument list. If you want to keep the same structure where you call another function from within another function, you will need to pass information from one function to the other. For example 
 function making_f(x,n,a)
'code for desired calculations
making_f=result
end function

function f(x,n,a)
'code
'the key in the code for a UDF is to have no direct references to the spreadsheet.
temp=making_f(x,n,a)
'code
f=temp
end function