Here's some more information about where I'm going with all this that might help...
I'm using the Field Collection module (I should've mentioned this) to group together various fields associated with video file uploads, such as either "uploaded videos" or "URL-based videos" (i.e. - YouTube), which essentially covers every kind of video one really needs for websites (excluding streams). So by using 2 fields (one being a file upload field and another being a link / URL field) I've been able to cover both types of video payloads that users will likely need help with. To make this whole interface more usable / friendly, I included an additional radio button field consisting of 2 values: "Upload" and "URL". By using jQuery, I've controlled the visibility of said video fields (Upload / URL), depending on the value of the radio inputs.
All this being said, I've decided to move the help text for these fields over into their own jQuery-controlled DIV container that's only displayed if a little question mark ('?') link is clicked on, hence my desire to move everything into a block--because if I get the help text into a block, I can then initialize the block to be something like "display:none" whereby in the jQuery, whenever the Add / Edit page loads, I can then set it to "show()" when the '?' link is clicked on, creating a nice and neat little help dialogue box for the users. It's a win-win all around that saves screen real estate, makes the Add / Edit page easier to use, and it will make it look overall much better / more professional.
I tried using field_info_field() on one of the forms I've been trying to extract the help text stuff like the "Allowed Filed Types" (file_extensions) and the "Max Storage Space Allowed" (max_filesize), but the resulting data structure doesn't appear to have this info in there as per what I'm seeing with dpm(field_info_field('field_video_upload')). Obviously, field_video_upload is the field I'm using to accommodate for uploaded videos.
After hacking away with many other Field API functions and losing more hair late last night in trying to figure out what constituted the various data structures (i.e. - entity vs. bundle vs. field) within the Field Collection data structure I was playing with, I finally came up with a way to get what I needed:
1.) To get the php.ini-configured max_filesize value, I've used $max_size = (int)(ini_get('upload_max_filesize')); (I plan on converting this to a string whereby I then plan on using the same format that Drupal uses to have he same sentence structure, etc.)
2.) To get the file types allowed part, I used $fields = field_info_instances(); and then traversed the structure to get the data I needed. Interestingly enough, if you do this FIRST, you'll see that each field's max_filesize array value is set to 0... I'm not sure why this is. I suspect that somewhere in core, it's not set? Who knows? But regardless, I simply set it before to the $fields variable and later on in the block code, access both the allowed file types and max_filesize using the two following variables:
$fields['field_collection_item']['<my field collection>']['<my field(s)>']['settings']['max_filesize']
$fields['field_collection_item']['<my field collection>']['<my field(s)>']['settings']['file_extensions']
This gets me what I needed. Now in the Add / Edit theme stuff, I can use the jQuery file I have to control the visibility and do whatever I need with the respective block while gaining a LOT of real estate in the field group area of the page! I wish I didn't have to go down this path, but by doing it this way, I didn't need to mess with any additional modules nor did I even really need to do much in the template.php file other than setting what jQuery file stuff I needed to be accessible in the respective content type. I love it when this stuff works. (Feel free to let me know if you have a better way to do all this.)
And happy new years to you too!