As Sam mentions, you can just have tasks. You can just use tasks for that. But I agree also with Sam, that you try to achieve something and a task should be driven by a requirement. An it would (in a team) also be required to plan this kind of work and also understand where your effort goes.
One way of doing this is to have a story for all the arbitrary tasks E.g. maintain application or small requests). At story planning level you would then realize how much time and effort goes into these things, even if you don't feel the particular requests don't require a story on their own.

From some of the articles, I got the understanding that we should try to keep story as small as possible (something that can be finished in one iteration ) so team can see progress from 1 sprint to another otherwise if you have a story with a task or set of tasks that takes too long to finish, the story would show uncompleted for several iterations.

Keeping the story small as well as meaningful at the same time from the end user's prespective makes it a challenging task to define the story at right granularity for the task(s) at hand. It is rather easy for a project that is dealing with web applicatin development for instance but seems much harder when you are trying to create new algorithms/methods for some reasearch problem. In that case, not all the tasks that you are working on are (directly) driven by end user's requirements.

It would help to see some examples for such projects.

A plan item such as a story is just a placeholder for some meaningful piece of work that is not trivial, testable, and likely needs several tasks to do it. Stories typically represent user requirements and are best expressed in the way 'As a role I.....'. However, you don't have to use that format or can rename the type (e.g. to implementation request) and use other summaries.

And you would still try to break your work down into chunks that are meaningful, cover a certain aspect that can be implemented and tested, ideally in a iteration. Because otherwise, you can not tick the work of as done in the iteration, you can not test it in the iteration and thus you can not measure progress in the iteration. So you do a lot of work in an iteration, but you can not see the value of the work in that iteration, because there is no tested, working outcome. To be able to see the complexity (story points for example) being done in the iteration is most valuable, because you can display progress and get better in understanding what the team will likely be able to do in an iteration and you can frequently check your progress against the plan.
 

Overflow....

You have to do work to break the work down into plan items and tasks that are meaningful and doable in an iteration, but it is worth the effort, because it allows better planning and prediction over time.